Subdomains and Bounded Context Relations

[Andrew.J]

Hi,

I am confused about relation between subdomains and bounded context.

I know that Bounded Context is the solution space and subdomain is the problem space, which is part of the whole domain as a whole.

In Bounded Context we have our own UL. Words that have double meaning, should be place in different bounded contexts.

Inside our Bounded Context we have a model, which tries to solve our problem. 

In perfect world Bounded Context would map 1:1 with subdomain. But mostly in legacy we overlap few ones in one bounded context. 

According to red book modules structure would look like that:

com.{company_name}.{bounded_context}.{domain}.{model}

And it perfectly fit to what Eric Evans wrote, that Bounded Context holds a model, which solves the problem.

Here's the first question, where information about our subdomain disappeared? I know I can write Context Map to see that model from this bounded context overlie some subdomains, but I would like to see, that information in code.

1. Is there any possibility to reveal, that information in code? For example, naming modules as my subdomain names. Where subdomain_a can reference aggregates from subdomain_b directly.

com.{company_name}.{bounded_context}.{domain}.{model}

                                                                                               .{subdomain_a}

                                                                                               .{subdomain_b}

2. Next thing that may happen. One of the subdomains may be a core domain and I would like use DDD approach there and only there. Above modules won't work like that, because I am doomed to one architecture. 

So for example:

subdomain_a - Core domain, 4 layers architecture, Domain Model

subdomain_b - Subdomain, 2 layers architecture, Anemic Domain Model + Services (CRUD)

subdomain_c - Generic Subdomain, 1 layer, few services (some additional things, not necessary needed in core domain)

subdomain_d - Generic Subdomain, 1 layer, few services (security)

Now should I model it like that?

com.{company_name}.{bounded_context}  

                                                                   .{subdomain_a}.domain.model

                                                                   .{subdomain_b}.model

                                                                   .{subdomain_b}.model

                                                                   .{subdomain_b}.model

If I would model it like, wouldn't be that a 4 Bounded Context for real? Because I have 4 models solving different problems (Then I need to go for bounded context integration patterns)?

If so, how to model it then? I can't have it in single model, because I want to reveal my highlighted core and focus on important things there. 

3. Supposing, that my proposal from second question is correct. How can I communicate between those subdomains?

Communication over HTTP, message bus/broker would be overwhelming. 

Can I depend on abstraction and inject adapters?

Can I go inside other model and call services directly? (If I would implement it as one model I would be able do it, why shouldn't I be able then, if I just splitted model for transparency). 

 

4. Eric Evans in chapter 15 talk about cohesive mechanisms. I couldn't find any code, diagrams of this neither in blue book, red book or internet. 

The example shown in book is about organisation structure and building it over graph model.

How cohesive mechanism should be implemented? As far as I understand I should create one model and extend it in another one. Correct me, if I am wrong.

Sorry, for amount of text, hope it isn't to much.

I just feel, if I won't understand it I will not move any forward. 

[Ben Kloosterman]

The term sub domain is not commonly part of DDD/ CQRS code AFAIK , ..  Possibly it just refers to a business area , which is modeled with a BC. Subdomain is common/ obvious  enough that someone could have used it.

1. I dont really see sub domains in code I have seen or written . It  would have to be a huge BC which is a bad thing BCs should be small. Possibly a BC within a BC feeding events to it. 

2...3   substitute bc for subdomain ..

4 the BC and aggregate design form the cohesive boundaries you don't do this in framework code , this is  business specific which is why  you cant make generic DDD/CQRS. This is quite important the aggregate structure guarantee that operations in that aggregate tree are consistent other relationships are may not be.. this allows you to just get the parts the business cares about being consistent. Everything as a transaction is bad  at scale.

Ben

[Andrew.J]

I am in greenfield and I don't want to overwhelm my domain model in BC.

But I am have problems, that are generic to my BC. I want to split them out of my domain model, but they won't be reusable, because they are specific to my model. 

According to Blue Book I have four options:

1. 1. An Off-the-Shelf Solution
2. 2. A Published Design or Model
3. 3. An Outsourced Implementation
4. 4. An In-House Implementation

I do not want to go for the first one, because I will need to translate models to make them understandable for my BC.

The second one I don't truly understand.

I want to go for the 4th option. How should I do then? Because @Bennie your answer doesn't provide me with guidance.

If I add library to my project it becomes part of my BC? Even, if I abstracted the way to do it in my domain? 

Or it becomes part of my domain only, if I use classes from library directly in my model? 

[Ben Kloosterman]

Its very hard to say without details CQRS is also about business modelling , you need business examples. You normally dont run non cqrs /ddd business code ( including libraries)  in your BC. Sometimes you may call a web service.  In many cases people are adding an infrastructure component in the domain.  In general (as i have no specific ) cqrs duplicates and keeps it simple rather than generic / shared.

For CQRS you should use a light framework  which loads the BC,s and handles the plumbing ( Look at simplecqrs its a great implementation with some subtlety ) . 

Sorry cant really help , need a lot more detail..

Ben

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Freek Paans]

Hi,

The way I understand it a subdomain contains a (highly cohesive) part of the model. So it would be incorrect to say that a BC and a subdomain should map 1:1. Instead, the model would be split up in several subdomains, but it would still be one model, and you'd still define a context where that entire model would apply: the BC. So it's not uncommon for a BC to "contain" multiple subdomains (including the core). The value in defining subdomains to me is identifying and communicating which parts of the domain model are really valuable, and making design/model more understandable/approachable by having multiple more or less independently understandable parts.

So in your situation: just add the new subdomain concepts to your domain model, but try to keep them as decoupled as possible (you talk about integration, so I guess there must be some coupling). Then make sure it's clear to everyone that this is separate subdomain, distinct from the core.

Cheers,

-Freek

[Andrew.J]

@freek Your last sentence opened my eyes.

Sounds like I miss understood the concept of generic subdomain. I thought, generic subdomain will be e.g working with filesystem/security, but it belongs to the infrastructure layer not to the domain layer. As it is not what about my domain experts talk about. That is why I was asking about libraries and it make sense to have no libraries at all in domain model @Bennie :).

@freek Looks like the first structure, that I provided would work well with your resolution. 

1. Eric Evans wrote, that you need focus on core domain and apply DDD there. So I should talk with DE only about the module which is my core and module which is for example generic, even if it still exists in my domain model I don't need to talk much, right? :) I am asking, because I was talking about whole domain model and I felt like some parts are just not so important like others and we were losing time there. 

2. Just to be sure. So subdomains coexist in the same domain model and are part of the same architecture (for example 4 layers). If I would create new code with 2 layered architecture (e.g domain model, services) I would be creating new Bounded Context?

[Aaron Muylaert]

I'm also very confused about the relationship between Bounded Contexts and Subdomains. Can anyone commend on my current understanding?

When a domain gets too large, the solution is to abstract into subdomains. You name and label those subdomains, spend most resources on the core subdomain(s). The core subdomains should be inline with the vision of the project. In a past project, I put the better engineers to work in the core domain and let a junior handle a subdomain. Or sometimes, you just want to use a different implementation approach to reduce costs in a certain subdomain. In these cases, I ended up with matching BC's and subdomains. I have added additional BC's based on internal structure of my team (for example a new junior that joins our team), in this case, the BC overlaps multiple subdomains.

I'll give an example.

The last application we built was for people who did analysis of something, when the analysis was complete, they published it. A lot of the things they analyze require reanalysis every x years, a new analysis would be made and result in publishing a new version. There were a couple of reasons they wanted this application:

1. There was ambiguity between analysis, certain parts of different analysis were the exact same concept but employees would invent their own names for it, ..

2. The current software didn't allow them to collaborate asynchronous. Employees would input their analysis and then export to excel to pass out to their colleagues and hold meetings to gather feedback.

3. They wanted to enforce a process on top of doing the analysis.

We quickly identified that there was little to no complexity in the entire domain. We realized that the entire process they wanted to implement was not in use today, a couple of stakeholders basically invented it, this was definitely not the core domain. Besides, there were a lot of cheaper ways to test this process compared to implementing it in software. The publication stuff, although important, it wasn't really the reason they wanted this software. The real reason was easier input of the analysis while reducing ambuigity between analysis and better asynchronous collaboration. After being on location for a while and seeing how these people worked .. we realized that better asynchronous collaboration did not really interest any of the employees .. at all. Some stakeholders just wanted something fancy. So we split up into BC's:

- Analysis

- Collaboration

- Process

Analysis, Collaboration and Process were all in one codebase. We considered Analysis to be the core domain so we made sure that Collaboration and Process had dependencies on Analysis and that Analysis had no dependencies. There was no real complexity in either of these BC's so the same people worked on all three. A junior joined our team and we created the Publication BC especially for him, this was a new application that would allow external companies to read the published analysis. Publication communicated with an API over HTTP. This HTTP API used all three BC's to retrieve the latest published versions of analysis.

Even after telling this story .. the lines between subdomains and BC's blur .. 

Op woensdag 23 december 2015 14:46:35 UTC+1 schreef freek:

[Aaron Muylaert]

Oh, it just hit me. Could it be that we actually implemented two Bounded Contexts? The nameless BC covering Analysis, Collaboration and Process and the BC dealing with Publication?

Op vrijdag 1 januari 2016 09:16:37 UTC+1 schreef Aaron Muylaert:

[Daris]

I am not an expert and I may be wrong, but I understand it like that:

Your problem space contains 4 subdomains: Analysis, Collaboration, Proceess, Publication.

If all of three Analysis, Collaboration, Process are placed within same model they are in the same Bounded Context.

For Publication you have created new model, which is Bounded Context of it's own. 

So you have 2 Bounded Context in your problem space, which are integrated via Consumer/Supplier pattern.

Not always Subdomain goes 1 to 1 with Bounded Context and it's okey.

[Alberto Brandolini]

Hmmm....

I'll try to clarify a little. SubDomains and Bounded Contexts exists in different conceptual levels. 

SubDomains (Core, Supporting and Generic) are part of the problem space. In my training company I can name a few: 'Product Definition', 'Marketing', 'Sales', 'Execution' (or 'Delivery'), 'Billing', 'Operations' just to name a few. They usually match pretty well with departments, but that's just a rule of thumb.

The classification between Core, Supporting and Generic is business-driven: Core is what makes your company special, what should be above your competitors par. This is the software worth writing in the best possible way. Supporting is hard to find off-the shelf, so it's something you might have to write, but with little competitive advantage: so what looked like brilliant in the Core, will look like gold-plating here. Generic is something you can easily find off-the shelf, so don't reinvent the wheel unless you find that 1) The wheel is badly flawed, 2) You can do significantly better 3) This will provide significant advantage to your enterprise.

Bounded Contexts are part of the way we model the problem. They live in the solution space. They represent consistent portions of the model and they're language driven. For those who remember the definition from Eric Evans: "a setting in which a word appears that defines its meaning"... it's pointing to the language we use to describe the problem.

And the language is the result of different forces: the development team, the company structure, the software involved, the people involved, the technology, time etc. But Bounded means that we are aware of the language and we define and - hopefully - protect the boundaries. The most significant way: we don't share the database, but we're also protecting the team from excessive turnover and so on. Being in a Bounded Context is what makes the magic of modelling happen: we're solving only one problem at a time and we can do it without trade offs.

The whole idea of a Bounded Context is necessary to allow developers perform at their best, by making the problem to solve simple and clear enough.

When talking about working with SubDomains (that will exist regardless of the software) and Bounded Contexts, the story gets more complicated.

In practice... there are still two major scenarios that need to be separated, because the forces are different. In Brownfield scenarios, we might read the existing Bounded Contexts, without worrying about how they should have been instead. In Greenfield scenarios we might have the privilege of designing our application according to its 'ideal shape' (assuming there's one).

In Brownfield ....shit can happen. It's been done before us. It's there. You can't deny its existence. A Bounded Context spanning multiple domains? ...yes. Just call it Big Ball of Mud and here you have the most common enterprise modelling pattern ever!

In Greenfield ... it's very unlikely to have BC spanning multiple subdomains. I just don't do it in my systems. Whenever I look for the 'ideal' BC i look towards the problem I am supposed to solve, and the best possible solution to that problem, inside its own BC. Then my job as an architect is to find a way to make the different model coexists and communicate (and Domain Events are great for that). When I say "it's very unlikely" it's because I like to solve simple problems: and a BC encompassing multiple SubDomains means "too many people to talk to" and also "finding a trade off solution" which are two of the things I hate most.

So normally, in greenfield scenarios, I have at least a BC for subdomain. Usually more than one, if I start splitting models according to heir purpose, like plan & execution, draft vs working, and so on.

Don't know if this clarifies or confuses even more. :o)

Have a good day anyway.

Alberto

  

[Freek Paans]

Hmm.. not sure if that's exactly how I view it. IIRC in the blue book Eric talks about things like money or time zones being generic subdomains. Models for those subdomains become part of your own model, but you don't put any emphasis on it, and instead focus on the core.

[Alberto Brandolini]

Yep, some subdomains are there *without* the corresponding department. :-) That was an oversimplification.

We agree on the emphasis, there is no point in reimplementing timezones, *unless* the standard solution is hitting you in the core. The usual solution for generic is to not reinvent the wheel, unless the wheel is Java.util.Date.

The Date example is interesting though: because in practice a Date in one BC might be a different concept from a Date in another BC (you won't need timezones for invoicing).

Alberto

 

[Freek Paans]

Yes, though both are probably generic :)