Understanding Domain Driven Design

In software development, a domain is a topic or area of knowledge that a software product is being designed for. You might also consider this the context in which the product is designed. When we talk about domain-driven design, we are talking about creating and architecting the software product in a way that makes sense for its domain. For example, one software situation that makes sense for DDD is an app that lets doctors order prescriptions for their patients.

Image By National Cancer Institute

We can start by casually defining the function using common language and identifying the different objects that might exist and their relationships to each other. For instance, the app will work by taking a patient and medication name from a doctor and sending it as a prescription to a pharmacy. Here, we have already defined four entities, the doctor, patient, prescription, and pharmacy. An entity is an object that is defined by its identity. For instance, a prescription will have a unique id number, and even if ten different patients are prescribed the same medication, they will receive the prescription that is specifically for them. In this scenario, we also have a value object, the medication. A value object differs from an entity because it is defined by its attributes. If two medications have the same name, then it is the same medication. If a doctor prescribes a medicine for one patient, it will be the same as a medicine of the same name they prescribe for another.

Image By National Cancer Institute

One of the most important aspects of DDD is context and vocabulary. The point of DDD is to create a sensible and legible common vocabulary to describe relationships. In this example, the medication is a value object because it makes the most sense in the context of our software. A doctor will likely not be concerned whether a patient receives Advil if they prescribe ibuprofen, since they are the same medication. If we were building a POS system for a pharmacy, the medication object may be an entity instead, since the price of Advil vs generic ibuprofen will differ even though they are the same medication. Despite both of these objects being modeled as “medications” they exist in different contexts in their respective domains.