A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.
114

The specification is virtually never sufficient. Developers who do not have domain knowledge cannot point out when the specification is in error (a frequent occurence most places) and make poor design choices.


110

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


68

First consider why you need to collect this data. Do not collect it if it is unnecessary. For example: You would like to address the individuals properly. Then, simply ask for their preferred form of address/honorific/title, such as “Mr.” or “Mx.”. This should be a free-form field, not dropdown list. There are more possible forms of address than can be ...


63

In my experience, having worked in 3 very different industries now, you can start out not knowing much about the domain, but you'll need to learn it eventually and someone will have to understand it to a detailed degree. The essential problem is down to the client-developer impedance: they want something but will only know it when they see it and you want ...


50

First name and last name are not useful concepts. Names work differently in different countries. In most Asian countries, the family name is written first, but it is still used for sorting—so you may put it in first name, and sorting will be wrong, or in last name, and display will be. And then there are countries like Iceland where they don't use family ...


40

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.


38

Martin Fowler's first law of distributed systems: "Don't distribute your objects!" Remote interfaces should be coarse-grained and internal interfaces fine-graned. Often rich domain model only applies within a bounded context. REST API separates two different contexts both having their own internal models. The contexts communicate through coarse-grained ...


31

The only argument that matters is what are the requirements of your system? Do you need to deal with just one culture? If so, conform to that culture. Otherwise plan for internationalization (as others have pointed out). Do you need to get data to deal with government forms, healthcare or other legal / system requirements? Follow whatever those dictate. ...


27

Validation of data entry is one of those things where everyone starts out trying to make it pure and clean and (if they're smart about it) eventually gives up, because there are so many competing concerns. The UI layer must do some forms of validation right there on the client page/form in order to provide realtime feedback to the user. Otherwise the user ...


25

Sometimes the term gender may be used when sex is meant. Sex is defined by a person's biological traits whereas gender is determined by identity. The standard for sex is codified by the ISO/IEC 5218 standard [download]. There are four available values 0 = not known, 1 = male, 2 = female, 9 = not applicable Similar values can be given for gender male ...


20

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


17

Primitive Obsession is using primitive data types to represent domain ideas. The opposite would be "domain modeling", or perhaps "over engineering". Would you create a DateOfBirth object and a Salary object? Introducing a Salary object can be a good idea for the following reason: numbers rarely stand alone in the domain model, they almost always have a ...


16

SOMEONE on the project needs to have fairly complete domain knowledge. That person may or may not be the developer. In Agile projects, the client project owner is that person, and they're working collaboratively and closely with the team. In non-Agile projects, somebody on the team needs to acquire that knowledge, but they usually don't, which is one reason ...


14

As you mentioned Healthcare, it's worth looking at the NHS Data Dictionary for an example, used in the UK as one of the national coding systems for health data (alongside SNOMED). Depending on whether you want sex or gender, there are two codings: for gender, it's the PERSON STATED GENDER CODE, whilst for sex it's PERSON PHENOTYPIC SEX CLASSIFICATION. As ...


13

I've no idea why Hospitals, Prisons, Nursing Homes, etc need their own classes. Nothing here makes me think they do. Why aren't these simply different instances of InternshipProvider? Not everything with a name needs to be a class. You need polymorphism if a Hospital needs the same method to have a different implementation than a Prison. Otherwise, these ...


12

so it would have been impossible to switch out to another ORM (not that we wanted to)). That seems wrong. A major advantage of the repository pattern is that you hide the data access logic and that it is easily exchangeable. So far it feels as though I put my business logic in my domain model and via repositories I would work with the ORM (which ever ...


11

There are a lot of excellent answers. I add my own because after reading them and searching I found that nobody mentions a key issue: bugs. If the team is not provided with enough people with enough authority and domain expertise, sooner or later bugs will inevitably creep in. Given a knowledge of the domain, there are impossible, or non-sensical values/...


11

What is a domain expert ? When you develop software using Domain Driven Design, the primary focus should be on the domain model, that is a representation of the domain in which the software will be used. Let's take the example of an accounting software. The domain is accounting, and to build your domain model, you need to identify domain objects (e.g. ...


10

If you put a person who knows only English and a person who knows only Japanese in a room, they wouldn't be able to translate from Japanese to English, in spite of being experts of their respective languages. For the same reason, even expert programmers with no domain knowledge are powerless at figuring out what they needs to build, even when they have a ...


10

The author makes the distinction between what is in the "board game" or not with the following example: eBay the website and eBay the board game both need buyers, sellers, items, and bids – but only eBay the website needs users, sessions, cookies, login/logout etc. See how he mentions "buyers" and "sellers"? These are just different names for "users", ...


10

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


9

Not sure that there is a 'one true way' answer for a design approach that, to be fair, is still evolving. First, DDD and CQRS are not the same thing although the CQRS folks seem to have derived from a DDD-influenced starting point. There's a lot going on in the DDD mindset and much of it has to do with properly defined boundaries of problems, communication ...


9

POST was deliberately designed to be "intentionally vague;" the result of a POST is implementation-specific. What prevents you from doing what Twitter and other API designers do, and define each POST method in the non-CRUD portion of your API according to your own specific requirements? POST is the catchall verb. Use it when none of the other verbs are a ...


9

What I am currently trying to do, which I am not sure if it is correct - is decouple the project models from a specific domain, and think of them abstractly. So, instead of airline booking system - it becomes a more abstract ticket booking system. Why? Your domain should be where your business rules live. Are none of your business rules specific to the ...


8

Without some aspect of business knowledge you end up with developers who don't ask questions and mindlessly code what the specs say. I believe it takes "Thinkers" to make good software not just people who can bang on a keyboard. Understanding not only "What" you are doing but "Why" and how it fits into the bigger picture helps provided greater satisfaction ...


8

You are intermixing entities should not access the repositories (which is a good suggestion) and the domain layer should not access the repositories (which might be bad suggestion as long as your repositories are part of the domain layer, not the application layer). Actually, your examples show no case where an entity accesses a repository, since ...


8

It depends. If your Account class shall be mapped to a relational database, then its not just a good idea, but proven practice, to use technical IDs for every table as PKs (and FKs, referencing those PKs). To my experience, separating the technical PK of all tables from the "domain keys" (like the "bank account number") works very well and helps you to avoid ...


8

Sharing a base model is against everything that CQRS stands for. If your models (write and read) are 99% percent then it is a CRUD architecture painted to look like CQRS. You must split the write from the read because the two models have different behaviors: the write model is concerned with ensuring the invariants and the read model is concerned with the ...


8

It's totally fine to pass a Domain service in an entity call. Say, we need to calculate an invoice sum with some complicated algorithm that can depend on, say, a customer type. Here is what it might look like: class Invoice { private $currency; private $customerId; public function __construct() { } public function sum(...


Only top voted, non community-wiki answers of a minimum length are eligible