Where to put business logic in DDD

Question

I am trying to find the best way to build an easily repairable and testable architecture. After going through several projects, I saw pretty good architectures, and I want to avoid future errors in my projects.

Let's say I am creating a fairly complex three-layer application, and I want to use DDD. My question is: where should I put my business logic? Some people say that this should be placed in services (service level), and that makes sense. Having multiple services that adhere to the principle of shared responsibility makes sense.

However, some people said that this is an anti-pattern and that business logic should not be implemented at the service level. Why is this?

Say we have an IAuthenticationService that has a method with a signature bool UsernameAvailable(string username) . The method will implement all the necessary logic to check if the username is available or not.

What is the problem here, according to the crowd “is it an antipattern”?

Answer 1

The service level itself is not an anti-pattern; it is a very reasonable place to place certain elements of your business logic. However, you need to be careful about service level design, ensuring that you do not steal business logic from your domain model and the objects that make it up.

By doing this, you can get a true anti-pattern, anemic region model. This is discussed in detail by Martin Fowler here .

Your IAuthenticationService example may not be the best for discussing the problem - most of the logic around authentication can be seen as living in a service and not related to domain objects. A better example would be if you had some kind of IUserValidationService to validate the user or, even worse, a service that executes something like process orders - the validation service removes the logic from the user object, and the order processing service takes the logic from the objects of your order as well as possibly facilities representing customers, delivery notifications, etc.

Answer 2

If you put all your business logic at a (implicitly non-existent) service level, you write procedural code. By separating behavior from data, you refuse to write object-oriented code.

This is not always bad: it is simple, and if you have a simple business logic, there is no reason to invest in a full-fledged object-oriented domain model .

The more complex the business logic (and the larger the domain), the faster the procedural code turns into spaghetti code: the procedures start calling each other with different pre-and post-conditions (in an incompatible order), and they begin to require ever-deployment of objects condition.

Martin Fowler's article on anemic domain models is probably the best starting point for understanding why (and under what conditions) people object to placing business logic in the service layer.

Answer 3

You should have 4 layers with DDD: presentation, application, domain and infrastructure. Everything that depends on the logic of precedents (the nature of the application, the components of the application workflow), goes to the application level (application logic). All invariant precedent logic (business objects, components of business processes) goes to the domain level (domain logic). The infrastructure level can have IoC, Cache, Repositories.