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.