DDD: How to divide application to Bounded Contexts besides e-commerce sample? [closed]

Question

We have a pretty big application here and I considering to refactor it a little bit to follow DDD guys guidance.

For now the number one issue with it is Bounded Contexts and Context Maps. Maybe I just don't grok it, but it seems to me just impossible to do division. For example we have User object all over the place and it's exactly the same User object: display name, id and roles. There is another example: we have CatalogItem object to help us categorize another entities all over the place. Do we have to introduce Bounded Context dependencies? Is there any guidance for this matter besides that tiresome e-commerce sample?

Answer 1

I found that, at first, bounded contexts and aggregate roots seemed like the easiest concept in DDD. This is until you actually come to implement a DDD application with a real world problem. There is no easy answer here. It totally depends on your business requirements (scalability, availability, latency, consistency, etc). The "correct" solution is the one that balances these concerns to best fit your need.

With the example you give, there are a few choices:

• One large bounded context
• Separate bounded contexts, with duplicated data (possibly implemented using a publish/subscribe messaging system)
• Pull Users and CatalogItems into their own bounded context and have other bounded contexts access them via a service

One thing to bear in mind is that querying needs are often very different to "writing" needs. It can often simplify your application design to have separate bounded contexts purely for querying. If this sounds like it might apply, look into CQRS.