What is a domain?

Question

I see this term a lot in the context of software architecture ("domain-model", "domain-driven-design" etc.). I have googled it, but I get tons of different definitions. So what is it really?

Answer 1

The word “domain” in the Domain Driven Design book by Eric Evans has specific meaning. It’s the thing the software is about.

Evans goes further though. In his view there are sub domains even with the same software. And this is the part of the book that deals with “Strategic Design”.

There are three “domains”: the core domain, the supporting domain, and the generic domain. Sometimes he’ll refer to these as sub-domains.

Evans also cares deeply about the actual business behind the software and the book is not just targeted at developers but also architects and managers who need to see how the software and the business can work together, and that’s what he is concerned with when discussing strategic design and these sub domains.

So, the core domain is the part of the software that represents both the competitive advantage and the “raison d’etre” of the software. It’s the part of the software that is why a customer would buy the software vs some other software. Usually, Evans sees it as the domain containing the smallest percentage of code. You can think of it as the most important 20%. It’s the part that you can’t really buy off the shelf and it might be just a single module or component of the overall software.

The supporting domain is still important and can be unique to the organization but isn’t as important as the core domain. Without it, the software won’t be as valuable and the core relies on it. It could be multiple modules in the software that you have written yourself and that perform important but supportive functions to the core.

The generic domain is the least custom and in some sense the least important part of the software. You may have written it in house but it might be more efficient to just buy it off the shelf or use well-known open source software. This part of the system probably isn’t specific to your overall domain, so for example whether you have a shipping system that routes parcels or a health records system that manages patients, the generic domain is the part of these systems that are common and just simply need to be there to function at all. This probably makes up the bulk of the system overall, but not necessarily so.

From a business perspective it’s important to decide what your core domain is and to focus your development resources there. Evans has many videos, particularly on the InfoQ site, where he explains these concepts in more detail.

So while we often talk about “the domain” in software, in the case of DDD, it’s not as simple as it might seem.

I should note that the concepts of DDD don’t necessarily exist in the wider software community. Other developers, authors, and product people may have different ideas and definitions, some more subtle and some less. Even other authors who have written about DDD might gloss over these concepts in Evans’ book, but I feel that the concepts are still useful when writing and planning a software project.

Answer 2

The domain is the real-world context in which you're attempting to solve a problem using software. Each domain comes with expertise, vocabulary and tools that are part of that domain.

A specific example of a domain could be something like "the automated machining of intricate parts using a high-speed rotating cutter." The software and hardware system that accomplishes this is called a CNC mill.

Another example of a domain is the accounting department at a corporation.

Further Reading
Bounded Context by Martin Fowler

Answer 3

It simply means the problem space you are working in. For example, if you were building an e-commerce website your domain would be "e-commerce" and would involve the processes associated with your client/company's sales practices. So a domain model would be something to represent a product or an invoice or a shipping record.

Answer 4

A Domain is an area of knowledge. It can be though about as an activity in which problems solved by your software exist. (Wiki, DDD Community)

Eric Evans in his book, uses cargo shipping to explain what DDD is. In his example, domain is everything about shipping. How cargo is moved, managed, shipped and tracked etc. It comes with its own, specific rules, language and processes. Those will create domain models, objects, services and so on.

When you create an application, you will have some sort of authorisation, just like the real world of shipping, not everyone can access warehouses. How users are authorised and how permissions are granted can be outside of the domain, because the information may not be relevant to the shipping of cargo.

Simply put: a domain is where you do business. If your business is shipping cargo - shipping cargo will be your domain. If your business is in authenticating and authorising personnel then this will be your domain.

Answer 5

From Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans:

Every software program relates to some activity or interest of its user. That subject area to which the user applies the program is the domain of the software.

The domain of an airline-booking program involves real people getting on real aircraft.

The domain of an accounting program is money and finance.

The domain of a source-code control system is software development itself.

The domain model, then is "a rigorously organized and selective abstraction of" the knowledge in a domain expert's head.

Palermo, in describing the onion architecture, offered this summary

In the very center we see the Domain Model, which represents the state and behavior combination that models truth for the organization.

Fowler, in turn, offers

An object model of the domain that incorporates both behavior and data.

If you are looking at more recent definitions, you are more likely to run into references that the domain model and the data model are different. I don't consider that a change of meaning so much as a change of emphasis -- modeling the behaviors (the way the data changes in response to information from outside the model) has richer complexity and variation than the different ways of writing things down.

Answer 6

Since you probably already have an idea of what is domain, I guess the next step you'll take is trying to define sub-domain, domain model and, more importantly, bounded context.

I start with putting my perspective of domain though.

Domain

Domain is the reality we inhabit: its entities, their behavior, laws they obey. It existed before us and will exist after us, in one form or another. Its existence doesn’t depend on our awareness. Marketers come up with new features and perform market analysis, Key account managers communicate with clients, software developers automate business-processes. That’s why domain is called a Problem space.

Sub-domains

DDD implies domain decomposing into sub-domains, to ease their modelling and comprehension. The very fact that you run a business infers that there is at least one predominant business-value. The one you earn money with. The one we started out our business for. So even if you do not know such a word like “Core domain”, it is still present. The same applies to sub-domains: probably you gonna need a bookkeeping, human resources, technical support — but it is secondary.

Domain model

There is no need in modeling extracted sub-domains in their entirety. There is a certain set of rules in each sub-domain that we are interested in. A rule set in some sub-domain that is necessary to achieve a certain business-result is called a model.

Bounded contexts

The most important thing is that bounded context is a logical boundary.

When both sub-domains and the core domain are defined, it’s time to implement the code. Bounded context defines tangible boundaries of applicability of some sub-domain. It is an area where a certain sub-domain makes sense, while the others don’t. It can be a talk, a presentation, a code project with physical boundaries defined by the artifact.

What's next?

If you're interested in how bounded context concept correlates with subdomain concept, how to define subdomains and bounded contexts, how to represent their communication with each other and how to organize teams with these concepts in mind, probably you'd be interested in this further reading.