CODEWITHSUNDEEP
architecturedomain-driven-designaggregateroot
Chris
Chris

Reputation: 7369

Domain Driven Design - Aggregate Root design issue

I am currently refactoring a system.

I've got the following situation:

The system is about providing information about companies across several business sectors. Each company can be active in one or more sectors. Companies can be participating in certain partner programmes. An a company can have one or more partner manufacturers (e.g. a garage can have a partnership with BMW/Mercedes) etc. All of these participations exist a given period of time (validity period). Additionally, a manufacturer like BMW is bound to one business sector. So a company can only be partner of BMW, if BMW is valid for the companies business sector. That is, because the system does not just maintain companies of a business sector like a garages, but also towing services etc.

So right now my design can cause some invariants.

Company -> Assignment (not slowly changing) -> Business Sector

Company -> Partnership (date from - to) -> Organisation <- Business Sector

Where Company and Organisation must share the same Business Sector assignment.

So right now, one could change the business sector assigment of an Organisation. Then this would the rule of having the same business sector to be invalid.

How would you model something like that?

Upvotes: 0

Views: 230

Answers (2)

guillaume31
guillaume31

Reputation: 14080

I see 2 DDD-compliant ways of enforcing this business rule :

  • DDD specifies that invariants in an Aggregate should be enforced by the Aggregate Root. If Company is your aggregate root, when you add a new partnership to it, it could check if the partnership complies with the business sector rule (possibly using a Specification pattern : EligibleForPartnershipSpecification for instance)

  • When changing an organization's business sector, it's a good idea to think in terms of "can the operation be performed ?" rather than "is this entity valid ?". It might mean checking if a Company in the company repository has a Partnership that would become inconsistent after the modification and decide what to do (possibly based on a Policy / Strategy pattern) accordingly.

Contracts are another smart way of enforcing invariants : see http://msdn.microsoft.com/en-us/magazine/hh205755.aspx (.NET)

Upvotes: 2

mikalai
mikalai

Reputation: 1736

Something goes wrong in your explanation. There are no aggregate roots in this design.

But logically probably the following statements conflict

manufacturer like BMW is bound to one business sector (1)

and

one could change the business sector assignment of an Organization (2)

If they do, you must avoid one of them.

If (2) is false, then everything is fine, right? You just don't allow such a change.

If (1) is false (or rather, not so restrictive), then organization bounds with business sector also should be limited to a certain period of time. In that case you make it in the same fashion like partnership's period limitation.

For example, you could set Partnership.EndDate to the date of Organization->Sector link change.

Additionally you could maintain some historical list of Sectors Organization participated in. Business rules would enforce periods match for Partnership and Sector assignment.

Hope that helps. (And actually generic design questions should go to programmers site.)

Upvotes: 0

Related Questions