Domain-Driven Design: Tackling Complexity in the Heart of Software

by Evans Eric

But the heart of this complexity is the essential intricacy of the problem domain itself.

If you’re trying to add automation to complicated human enterprise, then your software cannot dodge this complexity—all it can do is control it.

An effective domain modeler can not only use a whiteboard with an accountant, but also write Java with a programmer.

Partly this is true because you cannot build a useful conceptual model without considering implementation issues.

But the primary reason why concepts and implementation belong together is this: The greatest value of a domain model is that it provides a ubiquitous language that t...

But the lesson of Eric’s experience is that the really powerful domain models evolve over time, and even the most experienced modelers find that they gain their best ideas after the initial releases of a system.

Although it has never been formulated clearly, a philosophy has emerged as an undercurrent in the object community, a philosophy I call domain-driven design.

The author describes Domain-Driven Design as a philosophhy that has emerged as an undercurrent in the object community (a pattern language as is my interpretation) and not as some meta-architecture and process designed from the top-bottom

When I took a close look, I saw that they lacked a domain model, or even a common language on the project, and were saddled with an unstructured design.

Could we also take into account here the case for anemic domain models, in the sense that a structure to the project could be provided over such objects (moving the domain logic to the use case classes for example) Via an use cases driven structure the project would be tightly integrated with the user flows, another fundamental element very important into attaining a comprehensible and maintainable codebase. (Don't forget the control flow vs task duality here)

Although their use of technology was not exemplary, it was the business logic that over-came them.

Their first release had ossified prematurely into a high-maintenance legacy.

But a poorly chosen separation of developer roles disconnected modeling from implementation, so that the design did not reflect the deep analysis that was going on.

When complexity gets out of hand, developers can no longer understand the software well enough to change or extend it easily and safely.

On the other hand, a good design can create opportunities to exploit those complex features.

Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user.

When this domain complexity is not handled in the design, it won’t matter that the infrastructural technology is well conceived.

When people learn design techniques, they feel excited by the possibilities. Then the messy realities of a real project descend on them.

They can’t fit the new design ideas with the technology they must use.

Or they don’t know when to let go of a particular design aspect in the interest of time and when to dig in their ...

Extreme Programming recognizes the importance of design decisions, but it strongly resists upfront design.

Instead, it puts an admirable effort into communication and improving the project’s ability to change course rapidly.

And although fear of unanticipated requirements often leads to overengineering, the attempt to avoid overengineering can develop into another fear: a fear of doing any deep design thinking at all.

Valuable models do not emerge immediately; they require a deep understanding of the domain.

That understanding comes from diving in, implementing an initial design based on a probably naive model, and then transforming it again and again.

Each time the team gains insight, the model is transformed to reveal that richer knowledge, and the code is refactored to reflect the deeper model and make ...

Then, once in a while, this onion peeling leads to an opportunity to break through to a much deeper model, attended by ...

Exploration is inherently open-ended, but it does not ...

Part III delves into modeling principles that can guide choices along the way, and techniques ...

A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.

An appropriate model makes sense of information and focuses it on a problem.

A domain model is not a particular diagram; it is the idea that the diagram is intended to convey.

It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective a...

A diagram can represent and communicate a model, as can carefully written code, as...

Domain modeling is not a matter of making as “realistic” a...

It is more like moviemaking, loosely representing reality to a particular purpose. Even a documentary film does not show unedited real life. Just as a moviemaker selects aspects of experience and presents them in an idiosyncratic way to tell a story or make a point, a domain modeler chooses a particular model for its utility.

And because the language is based on the model, our natural linguistic abilities can be turned to refining the model itself.

The binding of model and implementation makes experience with early versions of the software applicable as feedback into the modeling process.

The heart of software is its ability to solve domain-related problems for its user.

All other features, vital though they may be, support this basic purpose.

Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology.

Learning about and modeling the domain is left to others.

Complexity in the heart of software has to be tackled head-on. To do otherwise...

To focus our exploration, we limited ourselves, for a while, to studying one particular feature. A “probe simulation” would trace the propagation of a signal to detect likely sites of certain kinds of problems in the design.

wrote a very simple prototype, driven by an automated test framework. I avoided all infrastructure. There was no persistence, and no user interface (UI).

This allowed me to concentrate on the behavior.

I was able to demonstrate a simple probe simulation in ju...

Although it used dummy data and wrote raw text to the console, it was nonetheless doing the actual computation of...

The concreteness of this prototype made clearer to the domain experts what the model meant and how it related to the functioning software.

From that point, our model discussions became more interactive, as they could see how I incorporated my newly acquired knowledge into the model and then into the software.

And they had concrete feedback from the prototype to evaluate...

As the engineers described new features they needed, I made them walk me through scenarios of how the objects interacted.