Thanks for your reply.

As you rightly mentioned that ACID do not scale well and I was also not inclined to have ACID across multiple aggregates.

Let's take a simple example of fund transfer from your book. A fund transfer involves at least two accounts and aggregates being unit of consistency should be updated in separate transactions to gain more scalability.

In order to achieve above, we need to have some process manager/ saga that can help us update multiple aggregates as a long-running business process.

Most of the DDD books that I read, excites the reader by emphasizing more on the DSL, consistency unit/ transaction boundary, but pay very less attention to process manager/ saga.

I forsee process managers/ saga to be implemented as reader monad, but it will be great if you can shed some light on this aspect also.

Thanks again,
As per DDD aggregate is constrained by transaction boundary. What that means is any update on an aggregate has to be performed in saparate trasaction or a transaction should only impact one aggregate at a time. Either in reaction to a command or event. If I take the example of fund transfer among two accounts in your book. I cannot see any such transaction boundary being honored there.

Can you please share what is the reason behind it?
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.

My bad! upon updating the scala version it started to work.
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.
In chapter 3 the smart constructor example for CheckingAccount and SavingsAccount does not work as described in the book. It gives "constructor CheckingAccount in class CheckingAccount cannot be accessed in object Account" error.