问题
I'm done DDD for a couple of years now and still its challenging when it comes to designing Aggregates. Thats the fun part of DDD and it makes your head spin. I'm asking this question since I'm architect in a project and we're in the middle of designing the model. Its an iteration when model evolves parallel with GUI and requirement gathering together with customer. Now to the problem. Our scenario is that we are facing some Aggregates that are growing into very large AR's. I think I'm good at finding Value objects and avoiding the anemic domain model trap. But I've never been in this situation. One example is that our system should represent a mobile telecom antenna. The antenna is located on a green field. But the antenna can have a shelter with equipment. Antenna can have microwave links, it can have fiber lines in ground, it can have radio elements, it can have power supply. Face it. If Antenna is terminated... all these dependencies are removed as well. Since they are part of the installation (except for the green field :)) But You get the picture. The antenna model is complex... And large AR's are inflexible regarding to concurrency locks, performance, memory consumption.
After reading Vaughn Vernons very good paper on Effective AR design http://dddcommunity.org/library/vernon_2011/ I realize that We need to start chopping our big AR's up in pieces.
My Idea is to do like Vernon suggest to move out for example MicrowaveLinks to a separate AR (even if its not in reality). The MicrowaveLink Entity, now AR, is reference Antenna by Id. In MicrowaveLink Entity class we have a value object property that is AntennaId. Our Uses cases support this scenario. We rarely list antenna and links together. So loading MicrowaveLinks is possible through a MicrowaveLinkRepository.ListByAntenna(Guid antennaId)
1) Have you done this AR split before and how did you do it? 2) Did you manage to support this AR --> AR relationship intact through both domain constraints and DB (we use EF 5 as ORM)?
My optimal goal is to be able to skip a Antenna.Microwaves Collection on Antenna. So Antenna are not aware if Links. The Links are aware of what Antenna they are mounted on. And At MicrowaveLink Entity I only want a AntennaId Property, with hopefully, a DB Constraints that make sure that Antenna exists.
I'm aware of that I can manually add FK constraints in Seed method in EF or in DB directly through T-SQL scripting. But can this relationship be supported in some way by EF5 Code First Fluent mapping?
回答1:
By the sounds of it you have an Installation AR. When requiring an AR in another you should model the contained AR as a only the ID in the container or a VO if required.
You need to have hard edges around your ARs.
Back to the Order / OrderLine example :)
An OrderLine seems to 'require' a Product but you shouldn't ever give a Product instance tot eh OrderLine. Instead only model, say, the ProductName and ProductId as a VO in the OrderLine. Now you have a distinct edge to your Order AR.
Hope that helps somewhat.
来源：https://stackoverflow.com/questions/17611635/reference-another-aggregate-root-inside-another-aggregate-root