The book I am reading Implementing Domain Driven Design gives this metaphor of flying in airplane viewing your childhood home and seeing something you are very familiar with at a detailed level from a high level so as to gain a new perspective. My hope after hearing that was that the author was going to eventually switch gears and explain things at a detail level instead of just giving the high level view that the book opens with. I am half way through Chapter 4 and I still feel like I am flying high waiting to see how the theory is applied to reality. I wish the author would explicitly tell the reader when they shift gears. For all I know he has already shifted I am just too clueless to consider the new style to be the detailed view.
I think the book definitely has useful information. I am getting the feeling though it is not the book I was thinking it was going to be. I was hoping for a book like "Domain Driven Design Practical Example Explained Step by Step". I am still missing how to take the theory and translate it to real code.
One interesting thing I read was about the Hexagonal Architecture. It is alternative to a layered architecture that allows multiple entry ports into the application. Our architecture definitely allows multiple entry points. Our thinking was that each major system would have its own entry point and that would allow us to change the internals of the domain but keep the entry point backwards compatible so as to not break those major systems with each domain change. Looking back now I am not sure that is really any better than having one versioned public API where systems that we couldn't upgrade could still remain on the old version of the API. The other main reason for this decision was that we could easily format the information in a way that each system needed so that the client code calling our API could be simpler. At least for our UI code I think this decision was helpful.
The author warns against business logic leaking out into the different ports. We definitely screwed that part up. Many of the stories I am work on now involve removing the business logic out of the port, putting it back into the domain, wrapping it with tests, and documenting the AC. Most of this business logic is how queries should work not commands. I think are application is definitely complex enough to merit the CQRS architecture described in the book. Separating out the queries would reduce some of the dependencies but not all of them. We still have cross aggregate validation to handle. Maybe he describes the solution for that later in the chapter.
Anyways I am going to keep reading. Hopefully I will glean something useful. I am still holding out for the DDD book that is mostly code with some explanations on why they made certain decisions.