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. matrix 
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.
.
Several authors have returned to my 1994 pattern language dubbed Episodes. This has been recognized as a founding work in the history of Agile. So an inquiry into roots of the now accepted and consequently diluted practices might want to know more about how Episodes came to be.
We spent some time this morning discussing congruence between things I had written and the speculative philosophy of Whitehead. This was in the context of Thompson Morrison's observations which were explored by viewing his Journal. riot
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
The "atomic" aspect of ACID DB transactions which makes writing records be an actual occasion (rather than an event that isn't an actual occasion, aka "dual writing"), situated within processing command and events in system.
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