DDD design understanding

Question

I've been starting to learn about DDD and I have couple of questions so that I can improve my understanding of it.

So a typical DDD architecture looks like this

Domain Layer => this layer should be technology agnostic and should contain the following

Domain.Entities (different from the persistence layer Entities, should contain only validation rules ? any other domain business should go here?)

Domain.ValueObjects (objects that do not require to be unique in the domain, should contain only validation rules)

Domain.Services (this layer should contain business logic that although related to an Aggregate, does not fit into the Aggregate itself. orchestrators for operations that require multi Domain.Entities and/or Domain.ValueObjects collaborating together)

Domain.Factories ( this layer is somehow not fully understood, i mean it's responsibility is to create Aggregates or what ?) Is it purely the Factory Design Pattern or is different from it?

Domain.Repositories (this layer is also ambiguous, except for the fact that i know that this layer is responsible to communicate with external services, what type of business logic should it handle?)

Anti-corruption layer (this layer should act as a gateway between the Domain layer and the Application Layer, it should be responsible with Translation of responses and requests from one layer to the other)

Application Layer => should only be used to expose data in a format easy to understand by the Client. Filtering is done in this layer (Linq-To-SQL) / (Linq-To-Entity)

Client (final layer) => should be free of any logic only exposes the models that the Application Layer Services provides.

other Layers as I see them

Shared.Kernel (Domain.ValueObjects / Domain.Entites (not AggregateRoots) that are shared across multiple Bounded Contexts)

Infrastructure.Domain.Common(shared across the entire Domain, ex AggregateRoot, BaseEntity, BaseValueObject etc)

Infrastructure.DataAccess.Provider(example EntityFramework / nHibernate/ MongoDriver , with whom this layer should communicate ? the Application Layer ?

Answer 1

DDD does not define a layering approach. It simply recommends that one be used. I would suggest reading up on Clean/Hexagonal/Onion layering. This approach is consistent with DDD and broadly endorsed.

Hexagonal

Clean

Onion

Don't let the different names fool you, the approaches are very similar, if not identical.

Answer 2

Honestly, the premise for domain driven design will vary based on the application requirements, business mission, and underlying architecture that may dictate the application. The simplest interpretation for domain driven design.

• Data Layer : An abstracted data layer, a separation of concerns from the graphical user interface.

• Domain Layer : Your business rules and logic, the fundamental foundation of the company requirements, mission.

• Service Layer : Not required, but to act as a mediator between the graphical user interface and the data layer. A clear concise translation between modeled data to a business entity.

• Application Layer : Your user interface, providing core business functionality to the user, in a meaningful way.

The important concept, no layer relies on one another. They're all independent and acting as a compliment to one another. You've dabbled into more specific contextual notions, all aren't relevant or viable in every application.

Based on your examples, you may abstract your domain outward to a point that the layer may be anemic, not holding enough relevant or useful information. A traditional tiered application, if written in a micro service approach, circular approach (clean architecture), or a hierarchical approach can be domain driven design. Because each approach or style is using the fundamental purpose of domain driven design, capturing the business purpose and mission.

An application isn't domain driven design because you have a layer. Your application will follow a series of principles to be domain driven design compliant. Those principles are to ensure your application adapts to the business shifts. Holding a core logic that represents the business, while pivoting as the business goals change throughout the life of the company. They often fall to the side of loose coupling.

Half of the above layers you mentioned, are patterns of complexity to solve a problem. All tools have a purpose, like a pattern, a screw driver is used for problem x, a factory may solve x, but repository may solve y. Not every pattern fits every use. They aren't cookie cutter solutions to problems.

A lot of material exist on the subject. Fowler, Evans, Vaughn, and countless others.

Answer 3

The place to start with DDD is "the blue book": Domain Driven Design by Eric Evans

a typical DDD architecture looks like

a layered architecture. Evans recaps four conceptual layers

• User Interface
• Application
• Domain
• Infrastructure

In Chapter 4 (Isolating the Domain), Evans points out

The part of the software that specifically solves problems from the domain usually constitutes only a small portion of the entire software system, although its importance is disproportionate to its size. To apply our best thinking, we need to be able to look at the elements of our model and see them as a system.... We need to decouple the domain objects from other functions of the system, so we can avoid confusing the domain concepts with other concepts related only to software technology or losing sight of the domain altogether....

Within the "domain layer", Evans recognizes two different sets of concerns.

Domain entities, value objects, and domain services model the business in the software (Chapter 5). In other words, these elements the model the concepts that your domain experts would recognize.

Repositories and Factories are life cycle concerns - not strictly related to the business as the experts would recognize it, but instead acting as the boundary between the application layer and the domain layer.

In Evan's formulation, the validation of business rules typically lives in the domain entities (not domain services). As is common in OO styles, the domain entities combine state (domain values) and behavior (rules for change) -- any change to a persistence layer entity (you are right, not the same thing) happens because of code executed by a domain entity.

Anti corruption layers more about integrating with an external data source (perhaps a legacy system) then they are about integrating with the application layer.

Implement a façade or adapter layer between a modern application and a legacy system that it depends on. This layer translates requests between the modern application and the legacy system. Use this pattern to ensure that an application's design is not limited by dependencies on legacy systems.

You might want to review the DDD Sample application available on github. It's a decent sketch of how the different pieces might fit together.

Note: these days, the layered architecture has lost ground to some of the other alternatives, and we are beginning to see more work on implementing the domain model with a functional core (rather than the OO style).