I’m sensing an assumption that contexts are a result of design activities - I would challenge that assumption and counter that in fact they are usually a result of domain analysis activities, especially when it comes to the DDD bounded contexts.
This does not preclude the possibility of boundaries being only discovered when coding is already underway - sometimes the facts that influence such a discovery are buried so deep that an effort would be cancelled due to Analysis Paralysis long before these details are unearthed.
One thing from DDD that doesn’t get enough attention is the practice of ubiquitous language:
A language structured around the domain model and used by all team members to connect all the activities of the team with the software.
Developers and domain experts have to share the identical terminology and mental model - to the point that they have to agree on a ubiquitous language domain glossary which includes all the terms and the detailed explanations.
I was once in a situation where I was continuously compiling and updating a unified domain glossary after every meeting for some time after project inception in order to unify the communications between the various stakeholders and developers who previously where using divergent terminology for the similar concepts and similar terminology for divergent concepts. It was during the act of talking to the domain experts and formulating this ubiquitous language that most of the boundaries started to reveal themselves.
So while, for example, a concept like product seems straight forward enough the relevant information about it can vary considerably among the various contexts like:
- Procurement
- Inventory
- Pricing
- Fulfillment
- Sales
- Marketing
which can lead to each context having it’s own, different product type which are all correlated via a correlation ID. Furthermore the product type used internally inside the context for collaboration between the context’s capabilities will likely be much more rich and detailed than the one it shares with its clients in order to stop the clients from becoming coupled to the context’s implementation details.
Now when it comes to fine-grained contexts it’s still about low coupling and high cohesion.
| | Tight Coupling | Loose Coupling |
===========================================================================================================
| Referencing | Point-to-Point | Via Mediator |
| Communication style | Synchronous | Asynchronous |
| Data model | Common complex types | Simple common types only |
| Type System | Strong | Weak |
| Interaction Pattern | Navigate through complex nested structures | Data-centric, self-contained message |
| Control of Process | Central control | Distributed control |
| Binding | Statically | Dynamically |
| Platform | Strong Platform dependencies | Platform independent |
| Transactionality | 2PC (two-phase commit) | Compensation |
| Deployment | Simultaneous | At different times |
| Versioning | Explicit upgrades | Implicit upgrades |
Asynchronous communication typically refers to (events). So loose coupling rarely comes easily nor cheaply.
But at times reversing the direction of dependencies is good enough: Dependency Inversion Principle in the Wild.
