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.

EJSarge (7) [Avatar] Offline
Hi Debashish,
Was very excited to get chapter 4 the other day. I'm finding this material useful - as well as requiring thought to digest.

Based on my attempts to implement some of it in my current project I thought I'd provide some feedback. This is more to provide you info on what one reader missed than anything else. I am implementing in Java and that deficiency may mean some of this is not useful.

What's not completely clear to me is the overall structure of the domain service and how the algebra should be wired in. I'm working from your book and the original DDD. The main change is understanding the change from having an object with methods on it that mutates the object itself to an external trait that does this. When I implemented this in a very small way it caused some surprise to my fellow developers. I currently have state change methods setting on the domain object itself that create a new domain object and return it. I'm about to move those particular methods into a separate class - but you can see how my mental model of things is a bit confused.

I also did a trial implementation of Lens. In my particular case the things I need to change are all on the aggregate itself (and not deeper in the hierarchy). Thus the whole Lens infrastructure looked very noisy for what it achieved. A copy constructor did the job quite nicely. You could possibly point out that Lens is for when you have a hierarchy underneath your aggregate (well, assuming I've actually understood the drivers for it).

Looking forward to the next installment.

BTW: Happy Birthday and I hope you're enjoying the cricket - happens to be hosted in my home country of NZ.
Debasish Ghosh (116) [Avatar] Offline
First things first - let me assure you that I am enjoying the cricket world cup a lot. And regarding NZ, it's a wonderful country. I took a long vacation last year in Jan-Feb 2014 and visited NZ - it's truly God's destination. And thanks for the best wishes on my birthday.

Now regarding the topics that u have raised, here are some points that you may find useful:

(a) Overall structure of domain service & algebra - I am in the process of refactoring chapter 3 to make this architecture clearer. And chapter 5 will contain a complete structure of a DDD based application using the patterns and principles that I discussed in chapters 3 and 4. Hope u find them useful.

(b) Regarding lens, I fully agree - for trivial updates, a lens may see noisy and a "copy" is a better abstraction. I will make this clearer while I am refactoring chapter 3. In fact one of the results of this refactoring will be a more elaborate section on lens.

(c) Regarding "I currently have state change methods setting on the domain object itself that create a new domain object and return it" - We need to understand why does the state change ? It's because of some domain activity which can always be modeled as a domain behavior. Will it not be more appropriate to give it a domain friendly name and expose it as a service ? You can have state changes as part of the service implementation.

Let me know if these make sense. Or we can discuss them more.

EJSarge (7) [Avatar] Offline
Hi Debashish,
Re: items a and b: Great! I'll look forward to reading them.

Re: domain services: Yes, I agree. That's where my refactor has ended up. I now have a fairly nice domain service that makes the domain actions happen. It's still not beautiful - I haven't got side effects into a shape I'm truly happy with.
I also implemented Try for the return from a database update in the repository. A whole lot of painful nested exception handling code went away in a puff. It was rather fun actually!
Debasish Ghosh (116) [Avatar] Offline
Regarding side-effects the code doesn't usually become as beautiful as Haskell. You can try with the IO monad but very soon you will be forced to use monad transformers, which is not pretty in Scala due to lots of explicit type annotations that you need to have. In chapter 5 I plan to have a section on using Free monads & interpreters where I will revisit this domain service implementation aspect.