I am designing an application, which will aid designing electric installations. I went for Domain Driven Design, as the topic is complex and the application will be growing with gained knowledge. However, I am newbie to this concept. For now, I have a problem to properly model the domain, especially to divide entities into aggregates.

I have defined wiring - Installation as a set of ConnectionPoints and Cables, which connect them. One ConnectionPoint has one or more Cables. Each Cable has a set of wires. I consider end of a wire as a Terminal, which we can connect to another Terminal creating a Junction. Terminals differ one from another, as wires have different colours and purpose. Junctions are made of two or more Terminals and can be done only inside a ConnectionPoint. I have illustrated it for a better understanding:

Illustrated ConnectionPoint

Besides Cables there are also Devices, which also have Terminals. They are also connected in a ConnectionPoint and their Terminals are treated the same way as Cable's Terminals. For each Device I must be able to track, where the Terminal is connected to (it might be a list of end points).

The problem, with the design, is the need of having references to Terminals outside of a Cable and Device entities to create Junctions and track connections. I could consider a Cable and a Device as aggregates of Terminals, as Terminals cannot exist without them and as a knowledge of Terminal's parent is important. However, each Terminal has also an identity outside of a Cable / Device and I have no idea how later in code and database I could keep knowledge of the connections made.

Do you have any ideas how could I model it? What questions should I ask myself to define a correct model and avoid keeping references everywhere?


The point of DDD is to allow express complex behavior in domain model and not just complex structure. And what you are describing is just a static structure. I believe DDD is not going to help you here. If you do have such behavior, then best way is to use TDD and slowly evolve the whole design. If you don't then you should look back at standard modeling techniques and don't use DDD.

Aggregates are great if you want to keep specific invariants on multiple different entities that are related, but they can be problematic when modeling complex relationships, just like you are experiencing.


An aggregate is an entity or group of entities that must remain consistent within any given transaction.
E.g. consider an electrical cable that has multiple wires: if you send current accross it, the current travels in the same direction on each of the wires. In a DDD app, you would have a method on the cable "TransferCurrent". That method would reside on the aggregate root (cable) and not on the wires, because current can't travel in different directions on wires of the same cable, that would make the cable inconsistent.
I hope that example somewhat makes sense, your domain is rather alien to me. But the gist is: look for entities or groups of entities that need to remain consistent within a given transaction.
Also keep in mind that aggregate roots can only reference by id other aggregate roots, not entities that may reside within an aggregate. The other way around is possible though.

  • Each wire in a cable is insulated (eg. Ethernet cable with 8 wires inside) and can be considered as independent unit. The only dependence is that, the wires go along with other wires of the same cable, so the cable forms a group of wires. The problem with Terminals is that I think I need to perform actions directly on them (connect with other terminals, find other end points etc.), but they cannot exist without a Wire or a Device, therefore I consider Device as an aggregate for it. – krzychu Nov 19 '13 at 12:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.