Domanda

I'm applying domain driven design aggregate pattern in my model. I follow the common DDD aggregate pattern example: Order is a root aggregate that manages one or more LineItem. In many of examples of aggregate pattern I found in the web, LineItem should not know anything about their Order.

I will use Hibernate JPA to implement this pattern. This will impose unidirectional one to many mapping from Order to LineItem. Based on the model, it is intuitive to make Order (the aggregate root) as the owning side.

And then, I read about https://fedcsis.org/proceedings/2013/pliks/322.pdf that describes anti patterns in Hibernate collection. It mentions that one to many as owning side is an anti pattern because Hibernate will issue additional queries. But, the anti pattern is exactly fit in my Order - LineItem aggregate pattern implementation.

How should I implement the DDD aggregate pattern in Hibernate (for example, the only way to add or update LineItem is from its Order) ?

È stato utile?

Soluzione

DDD points out the best way to design, and then lets you optimize from there. In this case, since your implementation details (IE hibernate) does bad things for the "best" design, you have to go with the more performant design. Assuming of course that there is in fact a performance hit.

So, build it right, then optimize. Premature optimization is the root of all evil: http://c2.com/cgi/wiki?PrematureOptimization

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top