4. Domain-driven design
Why it matters
You simply cannot create one single architecture that covers the entire enterprise. The architecture must vary with the terrain.
Let’s take a Telecom operator as an example. The Telecom Network, including activation and deactivation of services requires one architecture. Services in the telecom network need high availability and the ability to manage high variability in load. Web storefronts that interface with customers, in the same enterprise, need a different architecture – the focus here is the interaction with customers and not with the network. Billing, as a final area, requires yet another architecture.
The Network, Web storefronts and Billing – all of these are domains. Domains are separated by a bounded context. Inside a bounded context, you have your own language, which is derived through object oriented design.
Let’s take a simple example by looking at the object Customer. A Customer has different attributes in different domains.
While the above probably feels logical, trying to accomplish the reverse – one Customer object across domains (“one object to rule them all”) – quickly becomes absurd.
If we would compile an enterprise list of attributes to describe a Customer across domains, this would result in over 1000 attributes. This means as soon as we send a customer object over an API, we would need to parse all these attributes, even in the simplest of scenarios when a customer number would do.
Applying domain driven design, is in all simplicity applying “divide and conquer” to a complex problem.
How it works
There are three basic practices that come with applying Domain Driven Design:
- Define domains and bounded contexts
- Allow for different architectures and models in each bounded context
- Make bilateral agreements when exchanging information across bounded contexts
Let’s illustrate this.
Bounded contexts
Three domains separated by bounded contexts, with bilateral agreements across borders, governing how to exchange customer information.
References
Domain driven design, Evens, Eric, Addison-Wesley, 2003
Bounded Context (article), Fowler, Martin, 2014
Case: Dodging the data bottleneck — data mesh at Starship, Medium 2021