Separation of application logic and domain logic in Clean Architecture

Question

I'm struggling with the separation of logic between entities and interactors or Use Cases. If I design the entities with DDD principles, each entity would have methods corresponding to use cases, instead of setters and getters. In that case, I would case, I would have roughly a one-on-one mapping of interactor classes and entity methods (perhaps with some interactors spanning multiple entities, and orchestrating more complex scenarios).

For example, I may have the following entity class:

Sale (entity)
+createSale()
+ammendSale()
+cancelSale() 
+shipSale()
+collectSale()

And the following command classes:

CreateSaleCommand
AmmendSaleCommand
CancelSaleCommand
ShipSaleCommand  # (this command may interact with the inventory service in a microservices context, or with the ProductStock entity in a monolithic context)
CollectSaleCommand # (this command may interact with payment and accounting services, or with the corresponding entities)

What do you think of this approach? I feel it may lead to a multiplication of artifacts without much benefit, with most commands being anemic classes that just pass requests to entities and return responses. Although they do take care of encapsulating the logic to access repositories and external services, while allowing the entities to focus exclusively on domain logic (their methods representing relevant business actions and events, and their private data representing business concepts and categories).

Answer 1

You don't need a one-to-one mapping of interactors and entities. I believe such a design would be harmful.

DDD is all about context boundaries and the ubiquitous language within those boundaries. When you really focus on creating objects to represent the language of the business, you'll find everything begins to shape itself a bit differently.

It seems odd to me that a Sale would create or ship itself. In the real world, I could picture a sales person making a sale. Then, a shipping department may manage the logistics to ship it. Perhaps, a sale would be created via an on-line shopping cart and shipped via email. Using this language as an example, lets explore a possible alternative design.

SalesPerson
+createSale(Customer, Product, Price)
+amendSale(Sale, Amendment)

ShippingDepartment
+shipSale(Sale)

Wait a second!? Don't we usually ship Orders? Maybe it should go like this:

SalesPerson
+createOrder(Customer, Product, Price)
+amendOrder(Order, Amendment)

ShippingDepartment
+shipOrder(Order)

Order
+constructor(Customer, Product, Price)
+applyDiscount(Discount)
+updateShippingAddress(Address)

Both are getting closer, but really our sales team doesn't call them orders and our shipping department only calls them orders. Also, orders are always created from the existence of a Sale, so we should reflect that as well.

SalesPerson
+createSale(Customer, Product, Price)
+amendSale(Sale, Amendment)

Sale
+constructor(Customer, Product, Price)
+applyDiscount(Discount)
+updateShippingAddress(Address)

ShippingDepartment
+shipOrder(Order)

Order
+constructor(Sale)
+placeOnHold()
+shipped(TrackingNumber)

And so, it continues to develop.

The way I deal with the separation of logic is to try and visualize that object in real life. Then, think about the properties and actions it has that are relevant to the business-need/use-case/feature.

---

Edit: How do you interact with the methods on an Entity in DDD?

Instead of using the Command pattern or other interactors, you simply use them directly:

salesPerson = new SalesPerson()
sale = salesPerson.createSale(...)

... 

shippingDept.shipOrder(new Order(sale))

Keep in mind that the two are not mutually exclusive. You can still leverage a Command pattern or Use Case/interactors if there's a need for it. You might have something like this (1 interactor to many entities and methods):

PartyUseCase(ShippingDepartment)
+prepareParty(SalesPerson, Customer)
    plates = ProductRepo.findByName('plates')
    forks = ProductRepo.findByName('forks')
    platesSale = salesPerson.createSale(Customer, plates)
    forksSale = salesPerson.createSale(Customer, forks)

    ShippingDepartment.shipOrder(new Order(platesSale))
    ShippingDepartment.shipOrder(new Order(forksSale))

    ...

Alternatively, there may be a simple script that's run once daily with nothing more than this (0 interactors):

orderRepo = new OrderRepository()
shippingDept = new ShippingDepartment()
for each order in orderRepo.getOrdersToShip()
    shippingDept.shipOrder(order)

Ultimately though, if you are creating a one-to-one mapping of classes to methods, you are creating unnecessary complexity.

Answer 2

The first thing that I thought of when I saw your sample architecture is "Can a sale create itself? Can a sale cancel itself? More importantly, can a sale ship itself or collect its own money?"

The words "Anemic data model" are only considered dirty words because someone somewhere decided that "true object orientation always marries data and logic together." But Data Transfer Objects are used all the time to pass data across boundaries, and they're the very definition of an anemic object.

Fundamentally, "clean architecture" is just one more flavor of layered architectures. The governing principle in all layered architectures is that dependencies should only flow in one direction. For example, the Business Logic Layer (BLL) needs to know about the Data Access Layer (DAL), but the DAL should know nothing about the BLL. This arrangement allows you to, for example, attach different BLL's (e.g. one for each department in the company) to the DAL without having to change the DAL itself.

Design concepts like this are difficult to discuss in isolation, so let's make this more concrete.

This is an architectural diagram from a sample trading application demonstrating best practices in software development called ArchFirst. Notice that it indicates two bounded contexts: the Order Management System (OMS) and the Exchange.

Now take a look at this diagram:

Notice that the methods on an order depend on the context in which it is used.

Also, I'm not necessarily averse to those methods being somewhere else other than the order object, perhaps in an OrderManager object.

Answer 3

Does not feel right to me.

There are two principles at least that agree with me. The first is: Keep-It-Simple. Why introduce any purely technical layer if there is no benefit? I think your gut feeling is right, it's just duplication of stuff that may or may not solve some future problem. The Keep-It-Simple approach tells us, if it doesn't solve a problem now, get rid of it.

The second is just concentrating on the business domain. The problem I have with "Commands" is, that they are purely technical. In other words, they do not belong to the business, to the ubiquitous language or the domain. It's cruft.

Also, if you are directly referring to Uncle Bob's Clean Architecture, here is an analysis of the Clean Architecture from an Object-Oriented point of view, in which I describe in detail why those ideas are fundamentally incompatible with object-orientation.

Answer 4

Interactors (I suppose that's what you mean by Commands) are similar to Application Services in DDD/Onion Architecture. They provide a hosting environment for the use case, or business transaction, to run, and they orchestrate calls to the domain and to external components.

For instance, you can have the following sequence

Start unit of work
Get entity from repository
Call entity method
Send email notification
Commit unit of work

This is in no way anemic or as trivial as "call entity method and return the response". It can be viewed as a responsibility of its own - you have to put this logic somewhere and if you put it in a Presenter, it could become bloated and incoherent.