The bulk of the text in these chapters (especially 4 and 6) revolve around separating “business logic” from … everything else. Chapter 4 discusses the concept of a Layered Architecture and how it furthers DDD. I would consider this a rather basic natural progression for growing developers. Even with completely ad-hoc development, layers will naturally coalesce:

  • Infrastructure: Most programs are based upon collections of libraries, because it reduces the effort required to get something done.
  • User Interface: This gets a bit iffy at times, because the UI code is often abstracted into part of the Infrastructure (e.g. I am writing a Swing application), and really that’s only half of the battle. It’s less natural to separate GUI API-calling code from the application, but the use of a library at all is a nudge in the right direction.

The description of Factories and Repositories seems rather extreme, but it does follow in line with unit testing. Testing a domain object’s behavior should be as separated as possible from testing the object persistance, because the persistance is really only a means to an ends. From personal experience, I also know that it’s a royal pain in the ass to set up test harnesses for a large DB schema, and the ability to separate that from all of the more meaningful (read: less infrastructural) testing is a definite boon.

In a way, I see the separations as a sort of two-dimensional cut. Layering the software provides several strata to handle, and separating domain “business logic” from “domain model persistence” slice the domain stratum into the meat and bones of a product, respectively.

Chapter 5 focused mostly on the pragmatic aspects of domain modeling. Namely, how can I apply these “pie in the sky” ideas to a real project? While it only touches lightly (addressing only a few technical issues of realizing a domain model), it is nice to see, and I hope to see more in later chapters. Without concrete grounding, no design concept can be adopted in the real world.