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

by Evans Eric

in the discussion of ASSERTIONS.

When the side effects of operations are only defined implicitly by their implementation, designs with a lot of delegation become a tangle of cause and effect.

The value of encapsulation is lost.

INTENTION-REVEALING INTERFACES carry us part of the way there, but informal suggestions of intentions are not always enough.

Briefly, “post-conditions” describe the side effects of an operation, the guaranteed outcome of calling a method. “Preconditions” are like the fine print on the contract, the conditions that must be satisfied in order for the post-condition guarantee to hold.

If you trust the guarantee of a post-condition, you don’t have to worry about how a method works.

If ASSERTIONS cannot be coded directly in your programming language, write automated unit tests for them.

Seek models with coherent sets of concepts,

Because ASSERTIONS are all in terms of states, rather than procedures, they make tests easy to write.

The test setup puts the preconditions in place; then, after execution, the test checks to see if the post-conditions hold.

Clearly stated in...

it is important to find models that make sense to people as well as satisfying the needs of the application.

and modifying arguments is a particularly risky kind of side effect anyway.

they made a discovery. It turns out that there was a compelling reason the original designers made it this way. At the end, the program reports the list of unmixed paints that were added. After all, the ultimate purpose of this application is to help a user figure out which paints to put into a mixture. So, to make the volume model logically consistent would make it unsuitable for its application requirements. There seems to be a dilemma. Are we stuck with documenting the weird post-condition and trying to compensate with good communication? Not everything in this world is intuitive, and sometimes that is the best answer. But in this case, the awkwardness seems to point to missing concepts.

Let’s look for a new model.

These are oversimplifications that don’t work well as general rules.

On the other hand, breaking down classes and methods can pointlessly complicate the client, forcing client objects to understand how tiny pieces fit together.

Because of this underlying consistency, when we find a model that resonates with some part of the domain, it is more likely to be consistent with other parts that we discover later.

This is one reason why repeated refactoring eventually leads to suppleness.

The twin fundamentals of high cohesion and low coupling play a role in design at all scales, from individual methods up through classes and MODULES to large-scale structures

Find the conceptually meaningful unit of functionality, and the resulting design will be both flexible and understandable.

By the same token, there are areas in any domain where detail isn’t interesting to the kind of people the software serves.

Clumping things that don’t need to be dissected or rearranged avoids clutter and makes it easier to see the elements that really are meant to recombine.

Observe the axes of change and stability through successive refactorings

CONCEPTUAL CONTOURS that explain these shearing patterns.

UBIQUITOUS LANGUAGE,

But it may never emerge from technically oriented refactoring; it emerges from refactoring toward deeper insight.