It’s about how an aggregate, entity or value object can be represented in code and the effect of one particular way of doing that.
I am just describing what could be the result of a design in a particular context. Note, that the model is not the only way you could design it. Let’s start with a quick example that allows us to highlight the challenges. However, in that particular case we’re relying on a particular persistence technology to be in use to derive exactly that information.Īlso, it would be nice if we could reason about the role of a type by looking at it without any other context. by analyzing that the domain type managed by a Spring Data repository having to be an aggregate by definition. Often a lot of them can be indirectly identified, e.g.
The primary focus of it is to see how we make the model more focused on DDD even in that case.Īnother aspect we’re going to touch on is how to make DDD building blocks visible within the code. Whether that’s a good idea is out of scope for this article. JPA annotations for easy persistence so that they don’t have to maintain a separate persistence model. Those ways usually make different trade-offs in decoupling the actual domain model from technology specific aspects.Ī lot of Java projects err on the side of still annotating their model classes with e.g. In Java applications the building blocks of Domain-Driven Design can be implemented in a variety of ways. implement persistence without polluting the domain model with annotations on the one hand and an additional mapping layer on the other. In this article I’m going to discuss an experimental idea to express some of tactical design concepts of DDD in Java code and derive the metadata to e.g.
When it comes to implementing building blocks of DDD, developers often struggle to find a good balance between conceptual purity and technical pragmatism. Make sure you rather read this one for the most up to date state of affairs. NOTE: This post has been largely superseded by “Architecturally evident code with jMolecules”.