The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

379170 (3) [Avatar] Offline
Hi Debasish,
Congrats for your book. I'm reading it with passion and enjoyment. I'm currently getting into chapter four which is really interesting. I love the explanation about what effects mean in the context of FP and how are managed by monads, i.e. Option for optionality, Try for error handling, etc.

However, so far I haven't read any section that address the problem of consistency in distributed domain services. I wonder if it's something that I'll find it in future chapters . I've had it a quick look ahead and I've found no mentions to Akka Persistence or Eventuate as popular choices to DDD and CQRS distributed architectures.

Causal consistency guaranties are important when it comes to deal with DDD and CQRS in distributed environments. Do you plan to address this topic in the book?.

Thanks in advance and keep up the good work!.


Debasish Ghosh (116) [Avatar] Offline
Hello -

Thanks for the kind words on the book. Glad that u like it.

Regarding consistency in distributed systems and designing consistent distributed domain services is a topic in itself that needs a separate book altogether. I don't think I can make enough justice to this topic by gluing it as part of this book. Already I am under pressure from the publisher that the book is exceeding the prescribed page count smilie ..

However I am thinking that I can try and add a section on this as part of chapter 8 where I discuss event sourcing. I certainly had ideas of discussing Akka persistence in depth, but could not do that for lack of space. Chapter 8 is already quite a bit long and has lots of code associated with it. Adding Akka persistence based implementation will add to that as well. I am also thinking if I can make an implementation based on Akka persistence as part of the online code repository - but having second thoughts as well as I have not covered any details about it (except some small stuff in the reactive streams chapter).

Let me think ..

379170 (3) [Avatar] Offline
Thank you very much for considering this contribution. I fully understand that the book might be too dense addressed in some depth the problem of distributed domain services but it is also true that it is a constant concern in real systems and applications, especially if offered as SaaS in the cloud.

It would be great if you could at least tangentially address the issue by providing some code in the repository. What I basically miss today is to combine a pure functional API with a distributed concurrency infrastructure such as Akka Persistence. Some preliminary ideas outlined in the book and in the repository would be helpful and would complete even further what is already offered in the book masterfully.

Debasish Ghosh (116) [Avatar] Offline
I will definitely try to have a section that touches upon some of the concerns. Still it's difficult to marry pure FP with distribution. The way I usually see it is that in most of the use cases distribution implies separate bounded context. So you can think of the entire model as a union of multiple bounded contexts. Within each BC you apply pure FP, do algebraic design, compose beautiful abstractions. But all algebra breaks down at distribution boundaries. You need to employ techniques like message passing to address this. I spoke about this in my talk at Goto Copenhagen in 2015. You can take a look at

Let me know if this helps.

379170 (3) [Avatar] Offline
Of course distributed programming has been always hard, right? smilie. It's true that you can distribute your computation on a bounded context basis but the problem usually arises when you need to scale a single bounded context and meet some consistency guarantees at the same time. It's when you typically end up relying on actor based computation, Akka Persistence, etc.

Precisely, you mentioned at the conference (great video by the way) that "using actors indiscriminately throughout your domain model makes algebraic reasoning hard". Yes, indeed!. What you win in terms of reasoning about concurrency you lose in terms of type safety and algebraic reasoning. At the end of the day, you end up writing code similar to the "summarizer" actor you depicted at the conference. Bad news...

I've been thinking lately if CRDTs could be the solution here, maybe in conjunction with Akka Streams. What do you think?.