Comment by stevebmark | Hacker News Reader

Comment by stevebmark | Hacker News Reader

Parent Full thread

Early on in the video they talk about designing specific type of "Customer" types that reflect the domain of the business, such as reflecting that Customers must be at least 21 years old to use the product.

Be very careful applying Domain Driven Design to your programs. To make software durable and survive long term, as much of the domain logic should be pushed into the user's world, and not locked into your code, poisoning it. You shouldn't need an engineer to make your program support onboarding a new type of Customer. That shouldn't require a new class and a new type. Think of the "extreme" anti-DDD software of spreadsheets. Almost every company in the world uses Excel or Google Sheets or some spreadsheet software. The business domain stays in user land, as it should. The more you use DDD, the more you poison and lock in your software into business rules that can limit the flexibility of the business, and force engineers to get involved for the business to try new things.

A ‘new type of customer’ could mean all sorts of things. In my mind it means a new sort of business for the company. It doesn’t seem crazy to me that software work should be required for a new kind of business—there would surely be new contracts needed from the legal department as well as different marketing and possibly accounting or billing. And if nothing new is needed, perhaps they aren’t really a new kind of customer after all. The DDD way to handle customers who must be over 21 is to have some type for the input of your business process, say customeOver21, and some function to which you give a customer and get back either a corresponding customerOver21. This makes sense if the kinds of customer are totally different but if, for example, you are a shop and some products may only be sold to customers over 21, then you probably want some different logic instead (eg each item may correspond to some requirements on the customer (or even some other state, e.g. max 2 of this item per customer) and these requirements can then be unioned together for all the items in a cart.)

But however you do things, I think you should work hard to ensure that it is easy to avoid accidentally treating, eg, a customer id as a transaction id or SKU id.

Excel just has a different domain: “people who want to write their own programs to solve … problems” or something like that.

"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.

> "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.

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.

wdym user's world?

Reply on news.ycombinator.com