My Journey in Learning Domain-Driven-Design part2 (Layers and Hexagonal Architecture)

In the previous part, we went through DDD definitions . in this part we will go through how DDD layers are structured and Hexagonal Architecture.

Layers:

ch4-p119 implementing domain-driven design [Vaughn Vernon]

Isolate the expression of the domain model and the business logic, and eliminate any dependency on infrastructure, user interface, or even application logic that is not business logic. Partition a complex program into layers. Develop a design within each layer that is cohesive and that depends only on the layers below. [Evans]

User interface Layer:

Application Layer:

Domain Layer:

Infrastructure Layer:

Important Rule:

Hexagonal Architecture:

ch4-p126 implementing domain-driven design [Vaughn Vernon]

It advances this goal by allowing many disparate clients to interact with the system on equal footing. Need a new client? Not a problem. Just add an Adapter to transform any given client’s input into that
understood by the internal application’s API. At the same time, output mechanisms employed by the system, such as graphics, persistence, and messaging, may also be diverse and swappable. That’s possible because an Adapter is created to transform application results into a form accepted by a specific output mechanism.

There are two primary areas, the outside and the inside.

- The outside enables disparate clients to submit input and also provides mechanisms to retrieve persisted data, store the application’s output (for example, a database), or send it elsewhere along its way (for example, messaging).

- The inside is the Application and the Domain model.

each client type has its own Adapter which transforms input protocols into an input that is compatible with the application’s API — the inside. Each of the hexagon’s sides represents a different kind of Port, for either input or output.

for example, we may use (messaging, REST) each one would have it’s own adaptor as well as if we want to persist our data into (database, in-memory data store) we consider Repositries implementation as adaptors (Adaptor E, F, G) as shown in the previous image.

with this architecture, the entire application can be designed and tested before the clients and persistence mechanisms exist.

Conclusion:

References:

Software Developer