Domain-Driven Design Distilled

2020-09-10T00:00:00+00:00

Domain-Driven Design Distilled brings DDD to life. Whether you’re a developer, consultant, or customer, it will help you understand it, so you can benefit from its power.

This book delivers powerful results in practice, which is why developers worldwide are rapidly moving to adopt it. This is an accessible guide to the basics:

What is DDD?
What problems does it solve?
How does it work?
How to quickly gain value from it?

You’ll learn how to segregate domain models using the powerful Bounded Contexts pattern, to develop a Ubiquitous Language within an explicitly bounded context and help domain experts and developers work together to create that language.

How to use Subdomains to handle legacy systems and integrate multiple Bounded Contexts to define team relationships and technical mechanisms.

Domain-Driven Design Distilled brings DDD to life.

Clean Architecture

2018-06-04T00:00:00+00:00

Code design principles (SOLID) #

Single Responsibility: a class should have one, and only one, reason to change. Or the new version: a module should be responsible to one, and only one, actor.
Open-closed: a class should be open for extension but closed for modification.
Liskov’s Substitution: objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
Interface Segregation: many client-specific interfaces are better than one general-purpose interface.
Dependency Inversion : one should depend upon abstractions, not concretions.

Component principles #

Component cohesion #

Reuse/Release Equivalence Principle: classes and modules (i.e. a component) reused together should be released together. They should have the same version number and there should be proper documentation such as changelogs.
Common Closure Principle: classes that change together should be grouped together, and vice versa. The single responsibility principle at component-level.
Common Reuse Principle: don’t force users of a component to depend on things they don’t need. The Interface Segregation Principle at component-level.

Component coupling #

Acyclic Dependencies Principle: no cycle in the dependency graph. Cycles couple components and, among other things, force them to be to released together. Use the dependency inversion principle to break cycles.
The Stable Dependency Principle: less stable components should depend on more stable components. Depend on the direction of stability.
Stable Abstractions Principle: stable components should be abstract, and vice versa. An example of an abstract stable component is a high-level policy which is changed by extension following the open-closed principle.

Architecture principles #

Setting boundaries #

Boundaries are lines that separate software elements. They separate things that matter from things that don’t, i.e. high-level components from low-level components. If a high-level component depends on a low-level component at the source level, changes in the low-level components will spread to the high-level component. Therefore, we place a boundary between the two, using polymorphism to invert the logic flow. This is the Dependency Inversion Principle in the SOLID principles.

Separating layers #

We can identify four main layers, although the number may vary:

Entities: objects containing critical business logic. For example, a bank could establish that no loans are granted to customers not satisfying some credit score requirements. Entities may be shared across apps in the same enterprise.
Use-cases: app-specific business rules. For example, the sequence of screens to execute a bank transfer.
Interface adapters: Gateways, presenters and controllers. For example, this layer will contain the MVC architecture of the GUI and also objects that transform data between the format of the database and the use-cases.
Frameworks and drivers: web frameworks, database, the view of MVC.

Chemaclass - ddd