Domain-Driven Design – Understanding Application Gateway in DDD

Bounded Contexts and Subdomains exist at different levels.

A Subdomain is a portion of the problem space, it's a natural partitioning of the system, often reflecting the structure of the organisation. So logistics and operations might be separated from invoicing & billing. Eric differentiates core, supporting and generic subdomains according to their business relevance in the given scenario.

Contexts are portions of the solutions space. They're models. It would be a good thing to have them, reflect the domains-subdomains partitioning ...but life isn't always that easy. And you might have bloated legacy domain encompassing everything, or more context in the same subdomain (i.e. old legacy app the replacement app somebody is building).

To have a Bounded Context you need to have a model, and an explicit boundary around it. Exactly what's missing in many data-driven application that use databases to share data.

Another - orthogonal - way to see it may be the following. Ubiquitous Language, the special condition where every term has a single unambiguous definition, doesn't scale. The more you enlarge it, the more ambiguity creeps in. If you want to achieve precise, unambiguous models, you need to make their boundaries explicit, and speak many little Ubiquitous Languages, each one within a single Bounded Context, with a well defined purpose.

If your different bounded contexts understand the meaning/purpose of a country differently, then you need to model it appropriately different in each one. However, if we are speaking simply of reference data of ISO codes and names, then I believe it's pretty fair and standard to stash it wherever is convenient and make it accessible to all interested parties. For example: a database, a configuration file, a web service, etc.

I also wanted to look at your model a little bit. The pieces you have listed could very well be "entities" in one "bounded context", depending on the company's structure. BCs often end up being defined around different areas/departments/teams, since that's frequently the natural boundary between "ubiquitous language"s. So for example, instead of Sales/Products/Orders I'd expect the BCs to be along the lines of Sales/Manufacturing/Warehousing.

Inside those BCs, you don't focus on the nouns. You focus on the use cases, and create models of the nouns that can fulfill the use cases. The methods on an "aggregate root" execute use cases and make the appropriate changes to the related models.

... all models are wrong, but some are useful.

Also bear in mind that each BC may use an entirely different system or architecture. A given BC may not merit using "DDD software components" at all, and most of them probably don't. DDD is less about prescriptive software components and more about the process of designing software. The point is to focus on understanding the company's bounded contexts, mapping out each context's ubiquitous languages, and modeling the code for that context using their ubiquitous language. That way when you interact with stake holders and refer to the code, it sounds to them like you are speaking in business terms they understand. And recognizing that the same word has different meanings in different BCs.

There are specific patterns brought forth by DDD (e.g. repository, specific layering, etc.) that are means to an end. But these patterns are not guaranteed to be the best patterns for every case, even within DDD. Just like DDD is not "the" answer for every project. You just have to do what your analysis suggests is the most practical thing to do.