Reputation: 151
In my current (JPA) project I have basically 2 entities. ChainOfClassesA and ClassA. Now ChainOfClassesA is basically a bidirectional list of ClassA (@OneToMany) and couple of other attributes. For me it seems that ChainOfClassesA is an aggregate root and thus has dedicated repository. Now, one use-case is to update ClassA. I know I could just create repository for ClassA but this would violate the rule "one repository for each root aggregate entity" as ClassA is not really an aggregate root, although this hints me that it could potentially be, or potentially I should "flatten ChainOfClassesA".
Now my question is should I be pragmatic and "just break the rules" and create dedicated repository for ClassA or follow the rules and replace birectional list @OneToMany in ChainOfClassesA with ID reference to ChainOfClassesA in ClassA. First approach is pragmatic and requires only a little work whereas latter approach requires also some other changes to the codebase. What are your thoughts? Especially why I should'nt create repository for non-aggregate-root (except maybe that one could then potentially use that repository so that transactional boundaries are no longer met)
Upvotes: 2
Views: 930
Reputation: 1210
If ChainOfClassesA is an aggregate Root and it has a collection of ClassA. If you need a usecase to update ClassA, you define a method on ChainOfClassesA object. I don't see any reason ClassA to have reference to ChainOfClassesA because any way it can only be used in scope of ChainOfClassesA. If EF allows you to do this, it not necessary means you should do it. If you define a repo per ClassA it means it can leave totally separate with its own lifecycle. And all other aggregates are eventually consistent with it. If you remove ChainOfClassesA, does ClassA should continue to live? If yes, Then ClassA should probably be a separate aggregate.
Upvotes: 2