How to decide what goes in the Domain or Application Project in a "DDD" solution?

Question

I am learning about DDD and domain-centric architecture design applied to .NET solutions.

However, I am struggling a bit about how to implement it.

I have some examples that came up to my mind recently:

• Filter/converting an excel file to another another kind of file json/xml and formatted following some business rules, be it a Console application or a WebAPI
• Computing the energy deployed or the distance given some train stations

How to decide what goes into the Application "layer" and the Domain "layer"?

I read:

• https://softwareengineering.stackexchange.com/questions/140999/application-layer-vs-domain-layer
• https://github.com/thiagolunardi/MvcMusicStoreDDD
• https://github.com/rafaelfgx/DotNetArchitecture
• https://github.com/EduardoPires/EquinoxProject
• https://github.com/ardalis/ddd-guestbook
• https://github.com/dotnet-architecture/eShopOnWeb
• https://github.com/HudsonLima/Product-API
• https://github.com/thangchung/magazine-website
• https://github.com/gigiogodoi/Blackbird
• https://github.com/JasonGT/DDDBNE2017
• https://github.com/felipeolimpos/base-core-ddd-mvc-ef-pg-ioc-proj
• https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/ddd-oriented-microservice

Answer 1

The Domain layer contains all the code that enforces business rules.

It should be technology agnostic (like specific databases - sql, no sql - or protocols - HTTP, REST) and frameworks agnostic. This means that it looks the same whether the Aggregates are persisted in an SQL database or in a NoSQL database, it is called from a HTTP controller or from a console application.

It should be pure, with no side-effects. This implies it should not do any I/O (read or write from any files). It receives all the data it needs as method arguments. For me, passing an infrastructure or application layer as argument to an Aggregate method call is also bad, even it is hidden behind a domain interface, because it can do I/O.

It should not depend on any other Layers. This means no imports or use from other layers (or whatever programming language construct you use in your programming language).

The Application layer is a thin layer that loads an Aggregate from the Repository, it calls the corresponding method on the Aggregate and then it persist the Aggregate to the Repository. It basically glues the Domain with the Infrastructure.