What Is Domain Driven Design and Why Would You Use It?

Domain-Driven Design (DDD) is a way to think about a software system from a top-down business-driven perspective.

Software is organized into Domains that deliver on business needs. Each Domain defines its own domain-model to store the data it needs and the model is closely aligned with that domain’s business-model.

A Slow Human Analogy

Compared to humans and manual data-lookup, computers are ridiculously fast. This makes it tempting during early development to ignore the computing effort involved with fetching data from another system to accomplish a task. Eventually though, these processing inefficiencies will break systems that share data.

I like to imagine my system designs and algorithms as being executed by slow manual human organizations such as government agencies. They cannot scale processing volume if they share the same building and store their data in the same filing cabinets. Of course they don't, and human organizations operate out of entirely separate buildings with entirely separate data structures and physical data stores that are tailored to their specific needs. We can safely assume that separate orgs have duplication of data between their filing cabinets and this works just fine.

Their processes also communicate asynchronously because it takes too long to expect an immediate response. Imagine if a clerk had to leave the building and travel across town to another building to fetch some data that he needs several times per hour. It simply doesn’t scale and no organization could survive if their processes required that.

Bounded Contexts

One of the more interesting and misunderstood concepts in DDD is the Bounded Context. This concept addresses the problems that a system will eventually face when it out-grows a central entity-model in a single database. This eventually becomes a bottleneck in performance and maintainability because of the complexity of too many engineers working on the same schema and too many projects having tightly coupled dependencies on a single entity-model and DB schema.

The wrong way to solve this performance problem is to use stored procedures in the database as this is only a temporary performance fix, but worst of all, it pushes the business logic even closer to the entity-model and into the monolithic database.

DDD is practically the opposite of the “stored procedure” approach. It moves the business logic far away from a centralized database and into the business-oriented domain that it is primarily related to. That domain should have its own database with its own domain-specific entity models, and the domains should communicate between each other asynchronously - perhaps using an event bus or event sync. It might look something like..

The Journey To A Domain Driven Architecture

Most startups begin with a monolith since they have to move quickly with a small team. Mirco-service architectures allow for larger organizations to be composed of smaller specialized teams who will own and maintain their services. Although the complexity for a single micro-service is lower than a monolith, this comes at a price of greater overall complexity for the whole system.

Many startups wait too long before they realize they need to scale beyond the monolith and take the short-cut to micro-services by adopting a free-for-all approach to building micro-services with shared ownership of the monolith. I've seen companies adopt an "Extreme Ownership" value, encouraging ownership of everything. It is forbidden say "that's not my job" or "I don't own that". My view on "ownership" is different - it's about assigning an owner for everything and knowing what you own and what you don't own. If everything is owned by everybody, then the ball gets dropped or chaos ensues because nobody truly owns anything. Adopting a policy where anyone can contribute to any code-base can end up with the worst of both worlds, having all of the complexity of managing multiple services, but none of the benefits of independent ownership, testing, and release cycles.

DDD drives clear ownership of software services delimited by business function. It's vital to invest the time to do an analysis of your company's business offerings in order to identify the domains. This will require several brainstorming sessions between your senior engineers and your product managers. These kinds of activities take time, and you should plan for them. You must document your domains and review them to ensure everyone has the same perspective.

A next step should be to identify what data models each of domain will be the custodian of. This can be challenging and you may have to decide between redundantly storing certain information in multiple domains that need it, or creating a common system of record, or both.

Once you are in alignment (or at least committed), you should then apply the Inverse Conway Maneuver to align your org structure to match your domain architecture. Not doing this will be an uphill battle.

Immediate Opportunities and Benefits of adopting Domain Driven Design

Break out logic and data from the monolith so that:

• multiple smaller teams can work on independent projects
• features can be released independently
• clear contracts can be defined around domains
• domains can be refactored and maintained without affecting other domains
• domains can be tested independently, which will improve quality

Break away from a centralized and deep-rooted authorization model in order to:

• Allow services to operate with elevated trust between domains and within domains.
• Move authorization logic to the domain level where it can be efficiently implemented, more clearly understood and tested.

Identify what the cross-cutting shared entity-model is and where it should live in order to:

• Keep a simplified and eventually-consistent shared truth about the system
• Allow domains to reference the common entities from their specialized domain-models

Clearly define ownership of code (that serves business functions) in order to:

• Build specialized knowledge within a team for a domain
• Have a clear responsibility for production support
• Monitor, own, and improve KPIs for the domain’s business objectives

Conclusion

I've worked at companies that span the entire range of maturity in their evolution from monolith to micro-services. I've often encountered many engineers who have vehemently opposed this next step in architectural evolution and yearn to stick with the simplicity of the monolith they originally built and see DDD as a further challenge and organizational overhead. However, I can't see any other option if a company wants to scale its engineering operations.

I hope you found these musings helpful. I will provide updates if I have other thoughts on how to drive these changes and overcome opposition. So far, I've had some success and some failures but that is a black-art to me ;-).