1

How would you handle a domain that shares much of the same business logic, but has slight variances in both the domain language and attributes of entities. These variances change by "region".

A fictitious example is a Real Estate System for managing residential Real Estate. The language used can vary slightly between State/Province, and attributes about the Real Estate can be more detailed in some States. There would be an Office in each State/Province managing the Real Estate for that "region".

Would you create a separate Bounded Context for each State/Province? So there would potentially be 50+ Bounded Contexts?

Would you create a single Bounded Context, and just handle the variances of language, and data through object inheritance or composition?

Ben Dempsey
  • 360
  • 1
  • 6
  • What about having a common basic functionality and have a separate plugin for each state incorporating specific parts? Common language can be reused here. Plugins can be implemented on different levels: at a code level using polymorphism or at a component level using different microservice for each plugin. It depends on your situation. – iTollu Dec 08 '19 at 19:27

2 Answers2

0

Let me start off by saying that I don't think there's a silver bullet here. As always it all depends on different factors. That's way my reaction is not a concrete idea but rather a set of consideration you and your team could take into account on the path to a decision.

If I would be asked to define a bounded context I would say that it is the setting where a word has a certain meaning or connotation. If we can agree one the above statement then one would immediately be tempted to create a bounded context per region or setting. That is, if the benefit you gain from having all those context contributes to the comprehensibility of the codebase. But if the context you are creating are really thin or you pay a heavy technical maintenance costs of having all those contexts I would strongly advise against going for multiple contexts.

I'm not certain but I feel that in your case one word will have the same meaning in each context only the word used will be different in each context. Whereas normally the same word used in different contexts has a different meaning.

I hope that this all makes sense and it helps you figure out your issue.

Jonas Geiregat
  • 5,214
  • 4
  • 41
  • 60
  • I like the way you described the language variances as "word will have the same meaning". In my case this would be true. I guess the next "thought" for my team to resolve is the variances in "Process". Overall process is the same, but the flow would have deviate because of differences in each "region" – Ben Dempsey Dec 06 '19 at 14:43
0

I reached out to Vaughn Vernon, one of the leaders in the area of DDD and I thought I would share his response (summarized by me).

Based on the limited information and examples I provided he brought up these points:

  • Metadata driven design would be more effective and efficient. Meaning, each "region" would have metadata to drive its flows, and data
  • Look at the State Pattern to drive regional situations
  • Look at the concept of DCI for ideas, but limit your attempts at actual DCI implementations as it can increase complexity of the code
Ben Dempsey
  • 360
  • 1
  • 6