DDD To Grok Whitehead

John Bywater has been sharing his journey to understanding Whitehead. In particular, John seems to see in Whitehead a definitive argument supporting the belief that domain-driven design's understanding of event sourcing does provide a general purpose architecture for even the most complex software problems. riot

One thing that I haven't paid enough attention to (pulled together very well) is the correspondence between Whiteheads's system and software. There's the match with event sourced DDD that I've mentioned: "domain model -> event-sourced aggregate -> domain event" is an example of "corpuscular society (nexus with many strands of personal order) -> enduring object (nexus with personal order) -> actual occasion". That's really the fish hook I have in my mouth, that's why I got caught on this stuff. It's like DDD is a single room I was living in, and I then I realised there's a whole mansion house to explore. As I've said before, there are four stages of an actual occasion, which just seems to correspond with the structure of the Alexandrian pattern. And then Alexander's statements in Timeless Way of Building: (a) that he is looking for patterns of events; and (b) that in the end (when you go through the "gate" and pass through a pattern language, the patterns don't matter any longer, because they have taught you to be receptive to what is real. That just seems to tie beautifully back to Whitehead's statement that there is no going behind the actual occasions to find anything more real. But there are a few other things that I haven't quite pulled into the centre of my attention, and perhaps more if I were to pay more careful attention. And perhaps now I can pay more attention to this. So firstly there is the structure of the book: which is quite definitely iterative (he talks of "recurring" to the topics): and incremental.(he talks of adding something to them with each recursion). Secondly, there is the notion of "concerns" that he says is addressing, which seems to be the same thing as we separate in software, when we work towards a "separation of concerns". I already mentioned the "atomic" aspect of recording which makes a set of model changes into a "thing": an actual occasion indivisible on the level of its logical unity (the statements in the transaction either all happen or none of them happen), but divisible in its physical actuality (resulting records can be updated or deleted individually). And the way that allows the processing of domain events to be considered atomically, as "process events". Also (bearing in mind Whitehead's proposition that each actual occasion has both a physical and a mental pole) that this "indivisible logical unity" corresponds to the settlement that takes place on the mental pole of an actual occasions, and that the "divisible records" corresponds to the physical pole. There's also the different ways a team can form together. In the end, the HEAD or a tag on some branch is built into a distribution, or directly deployed. But whichever is the latest changeset, and however many other branches there are, there's a single line of changes going back from the point that is released to the initial empty state of the repository. So that's a set of changes with serial ordering, an enduring object with personal order. And by comparison, a team of developers (and other roles) is a corpuscular society. So there are different ways in which the experience of the members of the team (as a corpuscular society) combine to make the working software (an enduring object, with a single strand of personal order). There are the sole or pairs of programmers with feature branches and continuous integration; solo or pairs of programmers doing trunk based development perhaps with feature toggles but with their local branches; and then mob programming with no branches so that their corpuscularity is merged into a personal order whilst the code is being written.

See Event Sourcing and Capturing the World

I haven't quite understood event sourced aggregate, but this article describing creation of such a thing in Rust seems to have helped medium

This answer at stackoverflow also feels informative for thinking about aggregates stackoverflow

John has written a python library or framework for building event-sourced things. A key and differentiating feature seems to be an application of atomic transactions at The Right Point in a sequence of events. This is a point I still do not completely understand, but leaving a note here for my future self to study more closely until I do understand. github

Why am I so interested? First, understanding event-oriented UI in GUIs and its effect on the code—as I learned from hypercard—was a defining transition in my early programming experience. Second, it was a DDD conference that brought Ward Cunningham to Denver where I could meet him in person. That meeting drew me fully into deep participation in federated wiki development. Explore DDD 2017