If a company sells a lot of things, how do I define the core subdomain?

Question

I'm working with a company that sells infrastructure as a service. They provide a lot of services such as cloud, hosting, database, ddos protection and etc. Each of them has different features and payment strategy. The problem is that, everything seems to be core subdomain to me since cloud, hosting, database make a lot of value to the company. So here's what I have tried decomposing these subdomains.

I'm new to the DDD and I think something is wrong here since there should be only 1 core domain here, but I can't choose one. Should I group them all and call it infrastructure subdomain, but that would mean the developer team has to deal with cloud, hosting and database which is too much I think? what would be the proper approach to decompose this kind of services.

Answer 1

...there should be only 1 core domain here

A company can operate in several business domains. For instance, Amazon operates in online retail as well as cloud services business domains.

Each business domain usually consists of sub-domains, core, supporting and generic ones.

If a business domain consists of several core sub-domains, each of which have high complexity and the way things are done provide competitive edge to the company in the respective overall business domain, than those core sub-domains are a fact.

It's important to note that sub-domains are already existing and are discovered while bounded contexts are modeled, designed and implemented, respecting any given constraints, to provide a system that best fulfills the businesses needs.

Should I group them all and call it infrastructure subdomain?

This is not up to you as a developer. You cannot define sub-domains, these are a given and need to be discovered together with business people.

What we can decide as developers, with consideration of existing constraints (legal, legacy architecture, cost, etc.) is how we cut the system's boundaries into bounded contexts that provide the best solution (implementation) to the respective problems (sub-domains).

If possible I would ideally strive for a 1:1 mapping between sub-domain and bounded context so that each bounded context can best implement the requirements of the respective sub-domain. This would also better adhere to the single responsibility principle, making sure one part of the system can evolve with the needs of just one sub-domain in mind and also does not change for different reasons originating from unrelated problems.

That all being said, it's of course up to your team to discover the respective sub-domains or exploring if the core sub-domains you listed are even separate business domains or core sub-domains of the same business domain.

If you should have several bounded contexts (one for each of your core sub-domain) or one bounded context that realizes all the core sub-domains makes more sense depends on your situation and constraints.

Keep in mind the bounded contexts enable physical boundaries, e.g. applications with their own life cycle and hosting model, or responsibility boundaries, i.e. for separate team ownership. Non-functional requirements such as performance and scalability can also come into play when designing your bounded contexts.

So bottom line either solution can be ideal in your situation but that's up to you to determine and decide.