I’m sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.
The big idea is "messaging" … The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.
It’s all very well being able to write one domain model to manage a single bit of business process, but what happens when we need to write many models? In the real world, our applications sit within an organisation and need to exchange information with other parts of the system.
Faced with this requirement, many teams reach for microservices via HTTP APIs but if they’re not careful, they’ll end up producing the most chaotic mess of all: the distributed big ball of mud.
In part two, we’ll show how the techniques from part one can be extended to distributed systems. We’ll zoom out to look at how we can compose a system from many small components that interact through asynchronous message passing.
We’ll see how our Service Layer and Unit of Work allow us to reconfigure our app to run as an asynchronous message processor, and how event driven systems help us to decouple Aggregates and applications from one another.
-
TODO: part2_context_diag
We’ll look at the following patterns and techniques:
- Domain events
-
Trigger workflows that cross consistency boundaries.
- Message bus
-
Provide a unified way of invoking use-cases from any endpoint.
- CQRS
-
Improve performance and scalability by separating reads and writes.
Plus we’ll introduce a dependency injection framework that uses type hints, just to annoy Harry.