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:
Here we rigorously separate the various concerns of our application or system into well-defined layers.
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:
Responsible for showing information to the user and interpreting the user’s commands. The external actor maybe another system or human. it contains only code that addresses user view and request concerns. it also may contain some UI validations but note that these validations are different from domain validations of business logic. components in the User interface layer are direct clients of the Application Layer.
Application Layer:
It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down.it may also be in charge of persistence transactions, security, sending Events-based notifications to other systems or composing e-mail messages to be sent to users.
Domain Layer:
Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here. even though the technical details of storing it are delegated to the infrastructure layer. it contains (Aggregates, Entities, Valueobjects, Domain services, Domain events)
Infrastructure Layer:
Provides generic technical capabilities that support the higher layers: message sending for the application persistence for the domain, drawing widgets for the UI. may also support the pattern of interaction between the four layers through an architecture framework.
Important Rule:
An important rule of this architecture is that each layer may couple only to
itself and below. There are distinctions within the style. A Strict Layers Architecture is one that allows coupling only to the layer directly below. A Relaxed Layers Architecture, however, allows any higher-level layer to couple to any layer below it. Since both the User Interface and the Application Services often need to employ infrastructure, many, if not most, systems are based on Relaxed Layers. Lower layers may actually loosely couple to higher layers, but this is only by means of a mechanism such as Observer or Mediator.
Hexagonal Architecture:
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:
That’s how we can structure our layers of DDD as I understand it we need to prevent layers leakage and with the help of Hexagonal Architecture, we can design and test our application without any client existence. it could be the foundation that supports other architectures required by the system like REST, Event-Driven Architecture, and employ CQRS. if you didn’t read the previous part you can check it out here.
References:
- Domain-Driven Design by Eric J. Evans
- Implementing Domain-Driven Design by Vaughn Vernon
- Domain-Driven Design Fundamentals course By Julie Lerman and SteveSmith
