0

I'm struggling to understand how to model my problem:

  • A Company can have many Teams.
  • Each Team must have a unique name per Company.
  • Reports for a particular Team must be retrievable, along with a list of all reports for a Company.

Just now, I have 3 Bounded Contexts's - Company, Team and Report. I believe I should move Team inside Company to enforce my unique name invariant - however, as I understand it:

"Nothing outside the Aggregate boundary can hold a reference to anything inside, except to the root Entity".

If I can only reference an AR from my Report AR, I cannot store which Team my report belongs to - just the company.

I have considered that Team may exist as it's own BC and also within the Company BC. Creation of a Team would then only happen from within the Company BC as an Entity. Here, the naming and invariant enforcement of that Team name can be ensured. The Team BC would then still exist and a Report can still hold reference to the TeamId from the Report AR. However, this would result in duplication of TeamId and TeamName - both within the Company BC and Team BC.

Does this approach sound ok, or am I missing something?

I'm confused if I have 3 BC's that should be 2 BC's, or missing a Team Entity concept within Company BC.

Maybe I'm confusing Bounded Contexts I only have/need Aggregate Roots - I'm not sure!

Gulp, help!

acairns
  • 485
  • 4
  • 12

1 Answers1

0

In your example Company and Team cannot be Bounded Contexts, it is entity (Company or Team can be Aggregation Root, it depends on the task), Company has Name identity, Team has CompanyName + TeamName identity.

Bounded Context is a cohesive set of models, which should reflect the meaning of the selected subdomain. Team and Company can form one BC, Reporting is another context.

If in your example Reporting is simply aggregate some information for easy display to the user, then this Reporting Bounded Context doesn't contain any Aggregation Roots, because there's no business logic and rules. In Reporting you should use simple DTOs to display the data.

ZeissS
  • 11,867
  • 4
  • 35
  • 50
Sattar Imamov
  • 562
  • 6
  • 16
  • Thanks a lot for your answer. Reporting is much larger than my dumbed-down version, with posing questions and answers. If I were to adopt your suggestion and have one BC containing both Company and Team, how would Report reference the team if it cannot store a TeamId? Or are you saying that Team can be a AR and Company can be an AR within the same BC? – acairns Mar 16 '15 at 18:28
  • @acairns One Aggregation Root can contain another Aggregation Root, e.g. Company AR can contain Team AR, if necessary. But in this case you cannot use Team AR outside Company AR in the same BC, because you can break invariant of Company AR. – Sattar Imamov Mar 16 '15 at 21:15
  • @acairns Essence of the proposal "Nothing outside the Aggregate boundary can hold a reference to anything inside, except to the root Entity" is that in one transaction you should perform operation in one BC, in one AR. At a time you perform some operation or in Company + Team BC, or in Reporting BC, if you cannot do that, then you should redesign you Contexts. If you can operate with Reporting BC without affecting another BCs, then it is quite normal that Report contains TeamId reference. – Sattar Imamov Mar 16 '15 at 21:15