During the requirements analysis, you might find that some concepts overlap the boundaries of business processes. For example, the same terms might mean different things and refer to distinct functions.

In the example, the overall domain is split into two areas of influence that might refer, for instance, to the input received from stakeholders in distinct departments. Or it can even be that different development teams are processing the diverse set of requirements, and both are trying to define a common piece of domain logic. The two areas have a few concepts in common. You have a few options for addressing this point and to avoid getting a brittle model: an all-encompassing context, a shared kernel, and distinct bounded contexts.

Using an all-encompassing context

Although the concept of a bounded context has always been one of the pillars of DOD, it seems to me that most architects and developers are sometimes scared of splitting the model into pieces, It’s as if breaking up the model for simplification reflects poorly on the architect’s ability to come up with a well-crafted, unique model,

When multiple definitions exist for a common term or concept, you can still consider them to be part of the same all-encompassing context, but this is a risky choice. Using a single definition for an entity has the side effect of padding the definition with details that might be unnecessary in other contexts.

The net effect is that you expose an API for the domain that potentially allows more than it should and leaves the responsibility of just doing the right thing on the developers’ shoulders. When it comes to this, there’s a statement I use often that’s really close to being another one of Murphy’s laws. if a developer can use an API the wrong way, he will.

Using a shared kernel

When business concepts are shared across two or more areas of influence, the likelihood of needing to make frequent changes is high. For this reason, implementing the shared concepts in a separated module—a sort of a shared kernel—is a better option from a maintainability perspective, even though it doesn’t fix the core issue of having entities with potentially way too many responsibilities.

Opting for distinct bounded contexts

Overall, whenever you recognize concepts that have different definitions in the domain, the best option is just to adopt different bounded contexts.

Overlapping concepts are common in business because you won’t find two domains that are absolutely identical. In general, the most recommended way to handle overlapping concepts is via distinct bounded contexts. By taking this approach, you guarantee that each concept has the most accurate implementation it can have, with no compromises, no ambiguity, and just the right number of responsibilities.

Any other option might just be the first step toward a true mess.

Giving each context its own architecture

Because a bounded context is a distinct area of the final system, it is expected to have the most appropriate architecture, regardless of what is being done for other bounded contexts. So it can be that the overall software solution is made of two or more contexts, each implemented with different technologies and programming patterns and languages.

For example, the web store of an e-commerce application can be an ASP.NET MVC application with a layered back end based on Command/Query Responsibility Segregation (CQRS) and the

Domain Model pattern to organize the business logic. “Selecting the supporting architecture.”) At the same time, the back office area of the site can be more effectively coded as a simple two-layer architecture with an ASP.NET Web Forms pre- sentation and ADO.NET data access. Mixing multiple supporting architectures in the realm of a single system is perfectly fine. 

We have always emphasized the importance of having a good website for your company because it can act as your best tool for marketing and sales. A poorly designed website can repulse people from your business and can cause you to lose customers before you even have them. Get in touch with HyperEffects to work on creating, enhancing and making the website of your company more user-friendly.