Reading chapter 3, I was struck by putting repositories in the domain service, which didn't seem right. My understanding of DDD was that domain services were places for domain logic that didn't properly belong with any given object. Application services coordinated multiple domain objects and saved with repositories. Since the functional modeling doesn't put the behavior with the data, I'm not sure if domain services are needed. It does seem like what's being created in chapter 3 is an application service.

Thoughts?

I am not very sure if I understand the concern. Have I mentioned anywhere in chapter 3 that repositories need to be part of domain services ? It's true I said we may need to inject repositories into domain services. I have demonstrated a use case where I injected AccountRepository into AccountService.

Maybe I am missing your point. Will you please clarify ?

Thanks.

Clearly, I didn't explain myself well. In my understanding, a domain service would not interact with a repository, since a domain service is a domain object just like an entity, except without data.

So, in the DDD book, Services are described starting on page 104. The example is actually of a funds transfer. The idea is that Account might have credit and debit methods, but the transfer method doesn't belong to either account and would be better in a domain service, FundsTransferDomainService. FundsTransferAppService uses the domain service and takes care of the non-domain effects.

It seems like what you're describing in chapter 3 is more properly an application service, because it is calling the repository.

Entities and value objects are defined with ADTs, so they map to those same concepts from OO DDD, but without the behavior.
The domain behavior exists separate from the entities and value objects, so that would seem to map to domain services.
Wiring the domain behavior with other things like persistence would seem to map to application services.

Did that explain it any better?

You are correct as per the classical domain driven design definition. But even in Evans' book he mentions that the line of distinction between the 2 can be fine.

If u take the example of funds transfer between 2 accounts, I am not sure what u will do in the domain service. The funds of each account need to be fetched from the database in order to validate the business rules. Trying to model this with 2 levels of services will lead to some indirections which I thought could be avoided in having a single layer of services. Throughout the book I have intentionally made this distinction fuzzy.

Thanks.

I agree with your point about fund transfer among different accounts (IDDD also has an example of AuthenticationService, enquiring about user and tenant from the repository), but what worries me is the part where you are storing it in the repository from domain service. Even for simple debit/ credit operation, the domain service is entangled with storage code. Let's leave this concern aside for the time being. What is your opinion about having transaction and security concerns, will they also be part of Account Service and what about referential transparency. I cannot now easily reason about fund transfer because it is no more a pure function.

I have created a gist (with refactored code) below, for you to reviewal. It will be great if you can comment on it.
https://gist.github.com/noorulhaq/08e98826c69f35734e29e8ade54129a5

Storing in the repository, handling transactions etc. can be done in a referentially transparent way till you reach the end of the world. You just have to use a proper implementation of the storage layer. Have a look at Doobie (https://github.com/tpolecat/doobie) which allows you to do so. Uses free monads and algebra and defers the implementation to the interpreter.

I have some comments on the gist as well.

Thanks.

Thanks for sharing the resource that can probably address my concern. It will be great if you can highlight, where how you have tried to address this concern in this book.