Interesting conversation on the optimal location for behaviour related to the domain. The discussion was around whether a Transfer of Funds from one Account to another Account should exist in a Domain Service (i.e. AccountTransferService) or right in the Domain entity (i.e. Account.TransferTo(account, amount)).

The real question is where does the ubiquitous language belong? How do we make the code more soluable? Where is readability at it’s optimal state?

I think that they pointed out the names for some things that I saw in the last code base that I worked on. Anemic Domain is when you have a thin Domain model (getters and setters only for example). The thing is that it isn’t all that bad, IF you keep the logic in the Domain Services. The problem that we had in the last code I worked on was that the business logic was in the Application Services which is an anti-pattern.

There also was a brief discussion about what DDD is. We agreed that it is a model of the business and a method for capturing ubiquitous language (ubiquitrons in David Laribee’s world).