DDD Infrastructure services

Question

I am learning DDD and I am a little bit lost in Infrastructure layer.

As I understand, \"all good DDD applications\" should have 4 layers: Presentation, Application, Dom

Answer 1

Why would you put repository implementations into Infrastructure ? They're not related to 'Infrastructure' at all imho.

According to Evan's Blue Book, repositories are a part of the domain model. Therefore, I put the repository interface inside the domain model. The implementation of the repository sometimes as well.

Infrastructure should contain 'infrastructure' code, which could be a service which enables you to easily sent e-mail over smtp, or code which abstracts DB access for you (so, some classes that you could use in your repository, but it is not your repository).

So, do not put your repositories into 'infrastructure', since they do not belong there. To me, the classes that can be found in infrastructure , are classes that you can use in different other projects, see what I mean ? Classes that are not tightly related to your domain model or application belong in Infrastructure. And a repository implementation is quite tightly coupled to a specific application. :)

Answer 2

Sticking with DDD definitions, a Repository is different than a Service. A Repository directly correlates to an Entity, often an Aggregate Root. A Service defines behaviors that don't really belong to a single Entity in your domain. You can absolutely find Services in every layer, though the types of problems they address differ from layer to layer and may be different from DDD's conceptual Service.

When working at the conceptual level, a DDD Repository differs from a DDD service in that it is specifically tied to Entity persistence. A Service can address any Domain, Application, or Infrastructure problem you may have.

You run into terminology clashes with DDD all over the place. For instance, a DDD Repository is NOT the same thing as the Repository pattern found in Martin Fowler's PoEAA book, though it may employ such a pattern. This is often a source of confusion for many people.

It helps with DDD if you always keep the Domain Model at the very center of everything you do. When it comes to layering DDD apps, I often choose Jeffrey Palermo's Onion Architecture. Check it out. Download CodeCampServer, an example app using this architecture. I think it's a perfect fit for DDD programming.

Good luck!

Answer 3

An unfortunate thing about DDD is the word 'Service'. What it should be is 'Domain Service'. Think of the Domain as entities and value objects, while Services are a way of dealing with actions, operations and activities.

As for the Repositories, they are just a facade that should behave like a collection to your domain. If you are using an ORM or writing your own, this is what all your domain objects should be going through in order to achieve persistence instead of those services directly.

Answer 4

Maybe it will help to see a potential project structure.

Possible assembly or package structure:

Project.Domain
Project.Infrastructure.Data
Project.Infrastructure.Components
Project.Infrastructure.Services

Possible namespace or folder structure:

Project.Domain
-n- Modules
----n- Account
-------f- Account.xx
-------f- AccountRepository.xx
-------f- Contact.xx
----n- Marketing
-------f- RegionRepository.xx
-n- Shared
-n- Services

Project.Infrastructure.Data (OR-Mappers)
-n- Tables
-n- Views
-n- Procedures
-n- Functions

Project.Infrastructure.Components (Generic)
-n- Mail
-n- Cryptography
-n- UI

Project.Infrastructure.Services (Special Operations)
-f- DoingSomethingService1.xx
-f- DoingSomethingService2.xx
-f- DoingSomethingService3.xx

Domain Entities and Value Types do not use Domain Services. The Application Layer uses the Services of the Domain. The Domain Repository objects use the Infrastructure.Data objects to return Domain objects.