5

I'm getting confused on how to define bounded contexts where there are shared concerns between them, and how to represent this with Domain Entities.

For example: A customer has many products in a Customer context A company has and a list of products in the Company context

So the customer is managed via the customer context, and the company via the company context

Given the contexts are in differnt modules.

If I want to provide the Company's address details with a product, how should this be handled?

Do I reference the module containing the Company context in the module containing the customer, or do I create a Company entity in the customer context specifically for use when interacting with customers?

Thank you

Andy C
  • 53
  • 1
  • 4

2 Answers2

6

You can have different representations of the same entity in different bounded contexts. Company in Company BC can be very different from company in User BC. All they have to share is some kind of correlation Id.

driushkin
  • 3,531
  • 1
  • 24
  • 25
  • Have you named entities differently based on the context in which they are used? E.g. call it `Company` in the company BC, and `Organization` in the user BC? Does this go against the establishment of a UL? Or Does a UL only apply within a context, even when entities span contexts? – Mafuba Jan 27 '12 at 03:26
  • 2
    UL should be applied within BC, this is what Evans himself says. – driushkin Jan 27 '12 at 09:49
  • 2
    For those wondering: UL = [UbiquitousLanguage](http://martinfowler.com/bliki/UbiquitousLanguage.html) – Laoujin Sep 12 '13 at 09:39
  • what if I have then many `BC` all need somehow to refer to `Company` wouldn't I have many `Company`'s duplicated all around? each with its own flavor but still much of duplication... – Jas Aug 12 '15 at 09:43
  • 1
    yes you will have duplication of some kind. but it's much better have these things separate so that they could be evolved independently. or else you are back to the age of monoliths where everything is coupled to some kind of 'domain' library which grows and grows to a point where it is no longer maintainable. – driushkin Aug 17 '15 at 13:02
  • 2
    and anyways 99% of the code we write today is just passing data around from one layer to another, which could also be regarded as duplicated effort. but somehow everyone is fine with that – driushkin Aug 17 '15 at 13:04
1

This is how we approached it in our project as well.

For one bounded context we used a contract as an Aggregate Root, while in another bounded context we used the contract as a value object/entity

In the first module/BC we had a big contract class with a lot of behavior in it, while in the second module/BC we had another contract class, which only contained a few properties with private setters.

This way it would be possible to separate the 2 BC's into separate assemblies of services in a SOA design even.

jochen.vg
  • 302
  • 2
  • 7