In domain-driven design, what is the relationship between the business functions of a system and the subdomains?

Question

Suppose an organization is developing an enterprise assistance and management platform with instant messaging, video conferencing, file cloud, online documentation, process approval, and more. The implementation of each function requires a complex technology, so how do you identify the subdomains of the platform? Or to put it more directly: Is a business function to be developed a new subdomain? Or is a business function a new business domain that can be subdivided into many subdomains?

Thanks to Ewan and Doc Brown for their patience and tolerance of my ignorance. I think I can finally ask the question that has been bothering me: "What are the criteria to define a subdomain? Can subdomains be divided into subdomains of subdomains? At what point does a subdomain become undivisible?"Some people think that subdomains are integral parts of the business areas that collectively form a company, and that each subdomain is handled by a separate department. Others argue that subdomains are relative. Subdomains can be part of an enterprise's business domain, or they can be as small as part of a department's business (for example, a Marketing Department might have its own subdomain).

Answer 1

DDD tries to get programmers to make the program match the business structure/thinking. In the business, a sub domain is part of the business which is divided off from the other parts, such as a "department". It's probably got its own "head of" manager and makes decisions on its internal processes without worrying about what the rest of the business thinks.

As such we are talking sizable chunks of process, employing at least several people. It's unlikely that a single new feature will require a whole new department in a business. But not impossible.

A smaller business might not be big enough to have departments, but still might have the same processes, which would be their own departments in a larger business.

The key thing I think would be to ask if the business thinks of the new process/feature/system as separate and by how much.

Answer 2

In DDD, the term "business function" doesn't have a specific meaning on its own. I looked it up in Evan's book, it does not appear in the index.

Personally, I am used to use the term for certain, isolated functionalities or features within the domain (or maybe within subdomains), hence on a different level of abstraction than the term "subdomain". For me, a business function is something which can be discovered througout the analysis of a (sub) domain. You might describe it in terms of entities, aggregates, services, and their behaviour, as well as with use cases.

Of course, single business functions can turn out to become larger than expected over time. This can happen during analysis, or during the evolution of the system. Then it may be justified to model a whole subdomain for something which was formerly called just a function or feature.

Since there is no universal authority on this, feel free to use "business function" on the level of abstraction which suits your needs best. Just make sure you explain to your audience what you mean by it.

For example, your question is an example for doing this wrong (please don't take this as personal critics, this is just factual). It gives a few examples ("instant messaging, video conferencing, file cloud,...), but the phrasing leaves it open to the imagination of the reader if that is what is meant by "business function".

so how do you identify the subdomains of the platform?

That question is mostly unrelated to the question about the term business function. It is a pretty broad question and not easily answerable here in a few paragraphs. Evan's DDD book contains 3 chapters about it (chapters 15-17, "Distillation", "Large-Scale Structure", and "Bringing the Strategy together).

For the example of your enterprise platform, however, I think each of the topics is so complex it might require a team on its own, and each of the teams may use a different methodology to develop their subsystem. Or, even more likely, you will not develop these components all newly from the ground. Instead, the task will be to integrate certain existing standard software components into the system. So before going into the technical modeling, one has probably start with creating the organizational structure first and make some decisions what not to develop, but to buy instead.

Answer 3

It is unclear what you are asking. On the face of it, you're asking how the application logic should be structured based on the tech stacks you're working with, which (if correct) is decidedly not how you should do that.

The issue here is that you seem to be hinging your understanding of DDD based on the semantics of the explanation you've been given, and this is not going to work out well for you if you approach it like that. Instead, it's much more important to understand the goal of DDD and what its domains represent, because you (as the developer) are the one who needs to be capable of assessing your requirements and what domain contexts best represent them.

It also seems that you are expecting DDD to do your analysis for you, based on this comment you made:

But once I switch to a new software product, such as the software in question, I don't know what to do.

That is how everyone starts out. This isn't a case of "I should be someone who already knows what to do with DDD". This is a case of "what techniques can I apply to further my understanding of this new product, so that I can then apply DDD to that understanding that I've built up".

DDD isn't a flowchart approach to understanding your requirements. It doesn't describe exactly how to technically understand every possible requirement, context or scenario. DDD is a guideline on how to model something after you've analyzed and understood it.

Your current question, as posted, does not indicate that you understand these prerequisites, nor do you explain them in the question so that we may provide an answer on the DDD-part of the question.

I think you're relying on DDD too soon in your process, which is hurting you because you don't understand your context/requirements and are somehow looking at DDD to help you with that (which it doesnt).

I strongly suggest you dig deeper into DDD training (though whatever media/education you prefer) and get a better understand of exactly what it is and what specific part of the solution it provides before you start using it, because misuse will cause you lots of grief in the long haul.