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?
asked Oct 23, 2017 at 17:56
-
14Unfortunately I think it's one of those words that doesn't have a clear definition and gets used in ambiguous contexts a lot. After seeing it enough though, you gain an understanding. My point is that you shouldn't expect to understand its usage even after reading all the answers you'll see here. It will take time.– aaaaaaOct 24, 2017 at 16:32
-
15@aaaaaa exactly ... Humpty Dumpty smiled contemptuously. ... "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean- neither more nor less."– emoryOct 24, 2017 at 19:55
-
3I don't think it's true that is has no clear definition. If you look at the normal webster definition, you see it's "a region over which dominion is exercised", "a region distinctively marked by some physical feature". Similar definition in math - the "domain" of a function. You can split a large something into domains or regions based on who is responsible for that region, or based on some criteria. Kind of like a module. So a 'domain model' (in my understanding) is a model that you can work with in your app's business logic. DDD also has to do with kinds of "regions".– Sava B.Oct 26, 2017 at 15:18
Add a comment
|
6 Answers
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.
answered Oct 23, 2017 at 20:11
-
1Re: your last paragraph: perhaps we should get some agreement on the core domain of software development? But, like agreeing on what OOP is, or Functional or any other term, I think that Humpty Dumpty won out a long time ago.– user251748Oct 25, 2017 at 14:08
-
@nocomprende no, these concepts are specific to a particular individual software in a particular organization in a particular time. So the core domain for MSFT Windows will be different depending on market conditions, customer expectations, etc. Oct 25, 2017 at 15:12
-
1I guess it reminds me of the old saying: "There are 2 kinds of people: those who divide people in to two kinds, and those who do not." But... for the second kind of people there would only be one kind of people... – infinite indirection error - system halted– user251748Oct 25, 2017 at 16:30
-
@nocomprende sorry I didn’t really understand your first comment— the part of “agreeing” on the core domain of software development was a joke. Oct 28, 2017 at 23:39
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
answered Oct 23, 2017 at 18:06
-
4Yup. When you read "domain", you could possibly substitute "(constrained to a certain) area of expertise or concern". Oct 26, 2017 at 8:51
-
2The interesting thing to keep in mind is that the domain of the software really has nothing to do with what humans are trying to achieve, or what they would understand. I am sure that the simple computer in my car is doing things to optimize the combustion that I know nothing of, and frankly don't care. So assuming that software is about human perspective and wants is a very dangerous misunderstanding. This might come in handy as software systems encompass larger areas, with increasing awareness and capability of choosing objectives. Hey, wait, didn't Asimov think of that, ever so long ago?– user251748Oct 26, 2017 at 13:37
-
1@user251748 - Well, I think it is about humans, and the processes they are involved in, just not necessarily about what people understand instantly. Sep 13, 2018 at 11:29
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.
-
7Um, given that websites have
domain namesalso known as domains, I think you should clarify how you are using the word domain here. Oct 24, 2017 at 22:40 -
@YetAnotherRandomUser - For me, it's pretty clear what he meant. ;) Nov 15, 2017 at 9:50
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.
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.
answered Oct 24, 2017 at 4:17
-
I would mildly adjust your definition from real-world activities to what the computer system is doing. For example, "The domain of a source-code control system is" - storage and retrieval of source code files. Domains are modeled, not to handle real-world things, but to make programming systems easier to construct and maintain. So the emphasis is on what a computer can do to facilitate that, not what humans can do. Digital X-Rays improve the sensitivity and image processing of the X-Ray process, they do not do anything for humans, and would be just as useful for unattended baggage scanning.– user251748Oct 25, 2017 at 14:04
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.
-
I would say that a domain for software is what the software does. It certainly did not exist before us, and it is entirely made up by us, to do things that we want to delegate so that they happen without our interaction. In other words, it is about a dream we had, which we want to forget. And, we rapidly do forget how the software works as soon as it is deployed. Software is a game better suited to computers to solve, we only did it up until now because we hadn't built the computers yet, to solve the problem that we don't want to be bothered by anymore. But, very soon...– user251748Oct 26, 2017 at 13:43
-
I didn't make myself clear in this part -- "before us", my bad. I totally didn't mean that domain existed before human race. By "us" I meant more like a software developers solving a problem of automating, say, business-processes in e-commerce. The concept of commerce apparently existed before them. So the developer's responsibility is to make it possible to delegate things to computers, as you said.– user286277Oct 26, 2017 at 14:56
-
Right. My point is that people think that computer systems are a way of dealing with the real world. But computers bring in a lot of ideas, requirements and concerns that simply weren't ever part of the domain. It is like saying that surgery is a way to deal with emotional problems. Well, lobotomy works, but emotional problems have little to do with the brain. And, my feelings are strongly affected by hormones and neurotransmitters, so are SSRIs part of biology, psychology, relationships, or are they a category unto themselves? Computers are about computers, not real things.– user251748Oct 26, 2017 at 22:16
-
1Computers are about modelling real things. Just another area where real things could be done, real business-processes could be implemented, real business-constraints could be applied.Say, 50 years ago I'd have paid $1 to the cashier in a store, now the whole process of buying could be without interaction with human being.Nevertheless my real money were withdrawn from my real bank account. So it doesn't matter what's involved in any process, computer or human or smth else. Probably it could be of some interest to you: medium.com/@wrong.about/…– user286277Oct 27, 2017 at 19:33
-
Money is not real. Business processes are not real. Everything that we can talk about is a concept, not real.– user251748Oct 28, 2017 at 1:46