Domain Driven Design Quotes

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

It takes fastidiousness to write code that doesn’t just do the right thing but also says the right thing.

A model is a selectively simplified and consciously structured form of knowledge.

The vital detail about the design is captured in the code. A well-written implementation should be transparent, revealing the model underlying it.

It is more desirable for Entities to have equals() and hashCode() methods that are based on the object’s unique identity rather than other attributes.

When you can, choose Value Objects to model integrations. This advice is applicable in many cases when consuming remote Standard Types.

there should be some learning when a domain model is discussed.

Knowledge crunching is an exploration, and you can’t know where you will end up.

To communicate effectively, the code must be based on the same language used to write the requirements—the same language that the developers speak with each other and with domain experts.

Developers are too wrapped up with technology and trying to solve problems using technology rather than careful thought and design. This leads developers to constantly chase after new “shiny objects,” which are the latest fads in technology.

Listen to the language the domain experts use. Are there terms that succinctly state something complicated? Are they correcting your word choice (perhaps diplomatically)? Do the puzzled looks on their faces go away when you use a particular phrase? These are hints of a concept that might benefit the model.

Developing software that delivers true business value is not the same thing as developing ordinary business software. Software that delivers true business value aligns with the business strategic initiatives and bears solutions with clearly identifiable competitive advantage—software that is not about technology, but about the business.

One of the patterns from domain-driven design is called bounded context. Bounded contexts are used to set the logical boundaries of a domain’s solution space for better managing complexity. It’s important that teams understand which aspects, including data, they can change on their own and which are shared dependencies for which they need to coordinate with other teams to avoid breaking things. Setting boundaries helps teams and developers manage the dependencies more efficiently. The logical boundaries are typically explicit and enforced on areas with clear and higher cohesion. These domain dependencies can sit on different levels, such as specific parts of the application, processes, associated database designs, etc. The bounded context, we can conclude, is polymorphic and can be applied to many different viewpoints. Polymorphic means that the bounded context size and shape can vary based on viewpoint and surroundings. This also means you need to be explicit when using a bounded context; otherwise it remains pretty vague.

outside the boundaries of its own skin—these things had driven the species to the edge of destruction. Worse, this one organism threatened the survival of all life on Earth. The Silencer’s makers did not have to look far for a solution. The answer lay in another species that had conquered the entirety of its domain, ruling it with unquestioned authority for millions of years. Beyond their immaculate design, the reason sharks rule the ocean is their complete indifference to everything except feeding, procreation, and defending their territory. The shark does not love. It feels no empathy. It trusts nothing. It lives in perfect harmony with its environment because it has no aspirations or desires. And no pity. A shark feels no sorrow, no remorse, hopes for nothing, dreams of nothing, has no illusions about itself or anything beyond itself. Once a human named Evan Walker had a dream—a dream it can no longer remember—and in that dream there was a tent in the woods and in that tent there was a girl who called herself humanity, and the girl was worth more to it than its own life. No longer. When it finds her,

Success comes in an emerging set of abstract concepts that makes sense of all the detail. This distillation is a rigorous expression of the particular knowledge that has been found most relevant.

Prefer references to external Aggregates only by their globally unique identity, not by holding a direct object reference (or “pointer”).

Architecture is important, but architectural influences come and go. Remember to prioritize correctly, placing more emphasis on the domain model, which has greater business value and will be more enduring.

When Events are delivered to interested parties, in either local or foreign systems, they are generally used to facilitate eventual consistency.

It seems to me that Scrum and other agile techniques are being used as substitutes for careful modeling, where a product backlog is thrust at developers as if it serves as a set of designs. Most agile practitioners will leave their daily stand-up without giving a second thought to how their backlog tasks will affect the underlying model of the business. Although I assume this is needless to say, I must assert that Scrum, for example, was never meant to stand in place of design. No matter how many project and product managers would like to keep you marching on a relentless path of continuous delivery, Scrum was not meant only as a means to keep Gantt chart enthusiasts happy. Yet, it has become that in so many cases.

Well, you either learn or you fail.

Simply stated, practicing DDD-Lite leads to the construction of inferior domain models. That’s because the Ubiquitous Language, Bounded Context, and Context Mapping have so much to offer. You get more than a team lingo. The Language of a team in an explicit Bounded Context expressed as a domain model adds true business value and gives us certainty that we are implementing the correct software. Even from a technical standpoint, it helps us create better models, ones with more potent behaviors, that are pure and less error prone.

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. When the domain is complex, this is a difficult task, calling for the concentrated effort of talented and skilled people. Developers have to steep themselves in the domain to build up knowledge of the business. They must hone their modeling skills and master domain design. Yet these are not the priorities on most software projects. Most talented developers do not have much interest in learning about the specific domain in which they are working, much less making a major commitment to expand their domain-modeling skills. Technical people enjoy quantifiable problems that exercise their technical skills. Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. 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 is to risk irrelevance.

Diagrams are a means of communication and explanation, and they facilitate brainstorming. They serve these ends best if they are minimal.

They show design constraints, but they are not design specifications in every detail. They represent the skeletons of ideas.

the model is not the diagram.

The behavior of running code is unambiguous.

documenting exclusively through code has some of the same basic problems as using comprehensive UML diagrams.

A document shouldn’t try to do what the code already does well.

Written documents should complement the code and the talking.

you may hear the UBIQUITOUS LANGUAGE changing naturally while a document is being left behind.

There is no need for explanatory models to be object models, and it is generally best if they are not.

The astrolabe was a mechanical implementation of an object-oriented model of the sky.

crucial discoveries always emerge during the design/implementation effort.

If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect.

Every software program relates to some activity or interest of its user.

This does not mean that effort is spent on modeling the “real world.” Rather, DDD delivers a model that is the most useful to the business. Sometimes useful and realistic models happen to intersect, but to the degree that they diverge, DDD chooses useful. With

A deep model has power because it contains the central concepts and abstractions that can succinctly and flexibly express essential knowledge of the users’ activities, their problems, and their solutions.

The domain model will typically derive from the domain experts’ own jargon but will have been “cleaned up,” to have sharper, narrower definitions.

Yet it is a legitimate pattern in some other contexts. In truth, there are advantages to the SMART UI, and there are situations where it works best—which partially accounts for why it is so common.

Factoring the constraint into its own method allows us to give it an intention-revealing name that makes the constraint explicit in our design. It is now a named thing we can discuss.

Whatever the cause, software that lacks a concept at the foundation of its design is, at best, a mechanism that does useful things without explaining its actions.

All public elements of a design together make up its interface, and the name of each of those elements presents an opportunity to reveal the intention of the design.

There are at least three ways of making associations more tractable. 1. Imposing a traversal direction 2. Adding a qualifier, effectively reducing multiplicity 3. Eliminating nonessential associations

If developers don’t realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it.

The complexity of a highly detailed interaction ends up being handled in the application layer, allowing domain knowledge to creep into the application or user interface code, where it is lost from the domain layer.

Success comes in an emerging set of abstract concepts that make sense of all the detail

Each service is meant to represent a domain or subdomain; in many ways, microservices is the physical embodiment of the logical concepts in domain-driven design.

If the implementer has state that is used in the computation, then the implementer is effectively an argument of the operation,

Complex object creation is a responsibility of the domain layer, yet that task does not belong to the objects that express the model.

This tight coupling of the application to the specifics of the implementation strips away most of the benefits of abstraction in the domain layer and makes continuing changes ever more expensive.

The DDD philosophy is not about following a set of rules or applying coding patterns. It is a process of learning. The journey is far more important than the destination, and the journey is all about exploring your problem domain in collaboration with domain experts rather than how many design patterns you can employ in your solution.

thorough.

Bounded Context is a specific solution, a realization view,

This makes Subdomains a very useful tool in assessing the problem space.

Just as YouTube started with manual curation, most networked products can start with manual efforts. This means exercising editorial judgment, or allowing users to curate content themselves. The App Store has millions of apps, so when Apple releases a list of “Apps of the Year” in the App Store, it aids discovery for consumers but also inspires app developers to invest in the design and quality of their products. Or platforms can leverage user-generated content, where content is organized by the ever-popular hashtag—one example is Amazon’s wish lists, which are driven primarily by users without editors. Similarly, using implicit data—whether that’s attributes of the content or grouping the originator by their company or college email domain name—can bring people together with data from the network. Twitter uses a hybrid approach—the team analyzes activity on the network to identify trending events, which are then editorialized into stories.

Software design is a constant battle with complexity. We must make distinctions so that special handling is applied only where necessary.

The goal is that not only can a developer understand what the code does; he or she can also understand why it does what it does and can relate that to the ongoing communication with the domain experts.

We have a microservice with a web API,

DDD isn’t first and foremost about technology. In its most central principles, DDD is about discussion, listening, understanding, discovery, and business value, all in an effort to centralize knowledge.

you’d learn which buttons did what, so that you could give one another instructions. “Press the red button near the flashing

An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes.

There are two patterns for decomposition: Decompose by business capability, which has its origins in business architecture Decompose by subdomain, based on concepts from domain-driven design

Extreme Programming concentrates exclusively on the active elements of a program and executable tests. Even comments added to the code do not affect program behavior, so they always fall out of sync with the active code and its driving model. External documents and diagrams do not affect the behavior of the program, so they fall out of sync. On the other hand, spoken communication and ephemeral diagrams on whiteboards do not linger to create confusion. This dependence on the code as communication medium motivates developers to keep the code clean and transparent.

fine-grained objects can lead to inefficient messaging in a distributed system.

A good SERVICE has three characteristics. 1. The operation relates to a domain concept that is not a natural part of an ENTITY or VALUE OBJECT. 2. The interface is defined in terms of other elements of the domain model. 3. The operation is stateless.

Try to completely eliminate bidirectional associations between VALUE OBJECTS. If in the end such associations seem necessary in your model, rethink the decision to declare the object a VALUE OBJECT in the first place. Maybe it has an identity that hasn’t been explicitly recognized yet.

Unless there is a real intention to distribute code on different servers, keep all the code that implements a single conceptual object in the same MODULE, if not the same object.

not design docs or architecture diagrams – was the only equivalent to design specifications found in other engineering disciplines.

Under the right circumstances, this can accelerate the growth of a business considerably while allowing the owner to retain ownership, reduced taxes, and lower interest rates.

Financial debt is the act of borrowing money from an outside party to quickly finance the operations of a business—with the promise to repay the principal plus the agreed-upon rate of interest in a timely manner. Under the right circumstances, this can accelerate the growth of a business considerably while allowing the owner to retain ownership, reduced taxes, and lower interest rates. On the other hand, the inability to pay back this debt on time can adversely affect credit rating, result in higher interest rates, cash flow difficulties, and other restrictions.

If the available tool does not facilitate that expressiveness, reconsider the choice of tools. An unexpressive implementation negates the advantage of the extra paradigm.

Across this linguistic divide, the domain experts vaguely describe what they want. Developers, struggling to understand a domain new to them, vaguely understand. A few members of the team manage to become bilingual, but they become bottlenecks of information flow, and their translations are inexact.

It takes fastidiousness to write code that doesn’t just do the right thing but also says the right thing.

these ad hoc solutions divert attention away from the model, and soon you are back to hacking and hoping.

Developing a good domain model is an art. But the practical design and implementation of a model’s individual elements can be relatively systematic.

all approaches are fine as long as they maintain the isolation of the domain layer, allowing domain objects to be designed without simultaneously thinking about the user interface that might interact with them.

Isolating the domain implementation is a prerequisite for domain-driven design.

frameworks can easily get in the way, either by making too many assumptions that constrain domain design choices or by making the implementation so heavyweight that development slows

One other case that drives people to combine FACTORY and REPOSITORY is the desire for “find or create” functionality, in which a client can describe an object it wants and, if no such object is found, will be given a newly created one. This function should be avoided. It is a minor convenience at best. A lot of cases in which it seems useful go away when ENTITIES and VALUE OBJECTS are distinguished. A client that wants a VALUE OBJECT can go straight to a FACTORY and ask for a new one. Usually, the distinction between a new object and an existing object is important in the domain, and a framework that transparently combines them will actually muddle the situation.

Although the REPOSITORY will insert into and delete from the database, it will ordinarily not commit anything. It is tempting to commit after saving, for example, but the client presumably has the context to correctly initiate and commit units of work. Transaction management will be simpler if the REPOSITORY keeps its hands off.

The rationale here is that as you move up the pyramid, the cost of upkeep goes up copiously while the speed of execution slows down manifold.

are those aspects of the system that do not affect functionality directly but have a profound effect on the efficacy of those using and maintaining these systems.

they almost always expect these features to be part of any system they use.

Wardley mapping,

EventStorming,

domain storytelling

there are three types of developers implementing microservices. Those who use DDD, those who don’t realize they do, and those who fail.

Jack Reeves in his 1992 C++ Journal article What is Software Design,

The split between design and manufacturing still exists, of course, but with software, we don’t need people for manufacturing. The compiler does it for us, which means that all work the people do is design work,

Executives and business experts should read this book so that they can articulate their vision and the core concepts that justify the need for the solution. Techniques will allow them to do this in an expedient manner and also gain empathy toward what it takes to implement changes quickly and reliably.

We cannot solve our problems with the same level of thinking that created them. — Albert Einstein

It may be necessary to further break down subdomains where the subdomain is still too complex.

evolve mature software solutions that will stand the test of time.

Areas of low complexity or that are unlikely to be invested in can be built without the need for perfect code quality; working software is good enough. Sometimes feedback and first-to-market are core to the success of a product; in this instance, it can make business sense to get working software up as soon as possible, whatever the architecture.

Supple design has a profound effect on the ability of software to cope with change and complexity.

Any team can write a software product to meet the needs of a set of use cases, but teams that put time and effort into the problem domain they are working on can consistently evolve the product to meet new business use cases.

Any team can write a software product to meet the needs of a set of use cases, but teams that put time and effort into the problem domain they are working on can consistently evolve the product to meet new business use cases.

Any team can write a software product to meet the needs of a set of use cases, but teams that put time and effort into the problem domain they are working on can consistently evolve the product to meet new business use cases.

Domain-Driven Design (DDD) is a process that aligns your code with the reality of your problem domain.

the process is to determine the decomposition into services. There are several strategies to choose from. One strategy, which has its origins in the discipline of business architecture, is to define services corresponding to business capabilities. Another strategy is to organize services around domain-driven design subdomains. The end result is services that are organized around business concepts rather than technical concepts.