CODEWITHSUNDEEP
domain-driven-design
Rohit Sharma
Rohit Sharma

Reputation: 6500

Sub-Domain with multiple bounded context and project structure

I have started reading few chapters of the blue book and have read the first three chapters of red book (Implementing Domain Driven Design). I have a two questions:

(1) Can a sub-domain have more than one bounded context? I am particularly looking at the example in Implementing Domain Driven Design book where there is a forecasting sub-domain sort of coupled/overlap with inventory. (Apologies if you have not read the book, but the idea is that there is a strong overlap between the two bounded contexts).

(2) How do I organize my project solution structure (I am using .net), are there any examples of real world projects that I can look at? Should I create folders namely sub-domain, core-domain, generic-domain and then specify the modules under it? I am struggling on how best to define my structure so that it shows the onion/hexagonal layers is in place.

Thanks in advance.

Upvotes: 2

Views: 1423

Answers (1)

MikeSW
MikeSW

Reputation: 16378

  1. Yes. The Domain is composed from multiple sub domains (if it is complex enough) and each are in fact a group of bounded contexts. The Domain itself can be considered a bounded context (BC) from the app point of view. A BC doesn't mean that it contains an unique model, but a specific representation of the business concept. So you can have a Book definition in multiple BC but in each, the definition is slightly different, ranging from full details to just an id. So the Book from Inventory is different than a Book from Sales for example. It matters how that BC understands a concept. The resulting model is valid only in that BC, although it can have the same name as the model from another BC. But that's what namespaces are for.

  2. There isn't a recipe for that, everyone structure their projects how they see fit. But most of the time you'll have at least one Domain project and UI, Persistence, Infrastrcuture projects. I think that the best structure depends on the app and on how the developers thinks so the way I do things might not be the optimum way for you. In a nutshell, structure the app as it makes sense for you.

Upvotes: 2

Related Questions