Question

Does the following image (i.e. a non-navigable composition relation) makes sense in an early-stage UML class diagram of a Domain Model?

I want to express that it will not be possible to do Company.Accounts, but that if the Company object is destroyed, all Accounts are to be destroyed too. My motivations are to avoid the Company class to become some kind of God-Object anti-pattern as discussed in this question. In DB terms: there’s a foreign key from Account --> Company. In the actual app, just about everything will be owned by the Company and, for performance reason, I don’t want to allow lazy/eager loading all the child collections from the Company.

I imagine the final diagram would probably have an IAccountRepository (see following image) but I find that it burdens the Class Diagram to put everything there. Imagine adding the extra infrastructure classes for each child collection. The class diagram would become unreadable!

How do you convey the idea in the Domain Model that loading is going to be “indirect”? Does it even go there?

Any references or industry standard on this?

Thanks.

Answer 1

You are mixing behavioral modeling with static model. The relation you set between Company and Account is OK if Company never accesses Account directly, but if you have functions in Company that access Account, then your model is wrong.

From what I know, there is no way to model that on the one side Company is composed of Accounts but that the accounts are actually stored in another place. Your second diagram is not correct, because if Company is composed of Accounts, then IAccountRepository should access them through Company and not directly.

IMHO, Account should have composition from IAccountRepository to Account, association from Company to Account, and in a sequence diagram of ICompanyRepository.deleteCompany that when a company is deleted, all of it’s accounts are deleted.