3 ms·

"Domain" is an undefined term, which is part of the problem of DDD. It's an arbitrary grouping of things. Sometimes people use it to mean a part of the business

"Domain" is an undefined term, which is part of the problem of DDD. It's an arbitrary grouping of things. Sometimes people use it to mean a part of the business, sometimes it's a group of models and actions on those models, and it's all a fundamentally flawed attempt to divide the real world into categories. It leads to ambiguous groupings of things where it's not obvious to put new functionality. And those groupings poison your software by trying to lock in very specific business ideas into software, making it inflexible. Excel is designed around _functionality_, and pushes concepts of "domains" into the users of the software, using it however they want to design their domains. If Excel had a "problem solving user" domain and a "business account" domain, etc, it would be terrible software.

fiddlerwoaroof 5y ago
I think the analogy is to “domain” meaning “the set of valid inputs to a function”. A business domain is the set of entities a particular piece of software is designed to work with. It’s a fuzzy “philosophical” term, but it’s not useless and paying attention to these seemingly arbitrary concepts makes a system much nicer to work in.
dragonwriter 5y ago
> "Domain" is an undefined term No, its not. > It's an arbitrary grouping of things. No, its not. Its the conceptual space in which the problem exists that software is solving. > Sometimes people use it to mean a part of the business For business software, this is approximately correct (its the part of the business context addressed by the system under design, which usually includes both some aspects of the business and some aspects of the universe outside of the business with which the business interacts.) > sometimes it's a group of models and actions on those models This is fairly explicitly wrong; that's a domain model, though confusion between models and the space being modeled is one of the most common cause problems in software engineering. > and it's all a fundamentally flawed attempt to divide the real world into categories Arbitrary, perhaps, but the divisions of the real world into “things the system under design is concerned with” and “everything else” is pretty fundamental to constructing a system. > And those groupings poison your software by trying to lock in very specific business ideas into software, making it inflexible. No, the groupings involved in defining a domain do not. There are other levels of analysis in DDD where that might arguably be the case, e.g., the assessment of consistency boundaries, but that's a different discussion. > If Excel had a "problem solving user" domain and a "business account" domain, etc, it would be terrible software. No system designed with DDD has multiple distinct domains.

fiddlerwoaroof 5y ago

I think the analogy is to “domain” meaning “the set of valid inputs to a function”. A business domain is the set of entities a particular piece of software is designed to work with. It’s a fuzzy “philosophical” term, but it’s not useless and paying attention to these seemingly arbitrary concepts makes a system much nicer to work in.

dragonwriter 5y ago

> "Domain" is an undefined term No, its not. > It's an arbitrary grouping of things. No, its not. Its the conceptual space in which the problem exists that software is solving. > Sometimes people use it to mean a part of the business For business software, this is approximately correct (its the part of the business context addressed by the system under design, which usually includes both some aspects of the business and some aspects of the universe outside of the business with which the business interacts.) > sometimes it's a group of models and actions on those models This is fairly explicitly wrong; that's a domain model, though confusion between models and the space being modeled is one of the most common cause problems in software engineering. > and it's all a fundamentally flawed attempt to divide the real world into categories Arbitrary, perhaps, but the divisions of the real world into “things the system under design is concerned with” and “everything else” is pretty fundamental to constructing a system. > And those groupings poison your software by trying to lock in very specific business ideas into software, making it inflexible. No, the groupings involved in defining a domain do not. There are other levels of analysis in DDD where that might arguably be the case, e.g., the assessment of consistency boundaries, but that's a different discussion. > If Excel had a "problem solving user" domain and a "business account" domain, etc, it would be terrible software. No system designed with DDD has multiple distinct domains.