Why ddd is important?
It wasn't magic. Whether you realized it or not, the model in the code was harmonious with the underlying domain. If that's something you want to happen every time, domain-driven design (DDD) is for you.
I've been an object-oriented software developer since the mid-'80s, and in that time I have seen many methods come and go. While I seldom achieve or sustain that elusive state of coding bliss, it has occurred several times, in different paradigms. The first was in structured programming (with big design up front). More recently, and more often, using DDD. Although anecdotes aren't evidence, I consider DDD to be the current best practice. Unfortunately, it isn't very popular, and those who use it typically don't do it terribly well.
That's a shame.
Every software system ever built has a model at its heart. If this model matches the underlying domain well, the software will accept enhancements more easily, and it has a much better chance of surviving and thriving intact for years. The model may not be obvious; it may exist only in the mind of the developers, but it exists nonetheless. Elegant designs are possible in any paradigm. If the model reflected in your code is aligned with the domain, the code flows.
It's this alignment that matters, and achieving and maintaining alignment is the fundamental purpose of DDD.
Your code has a model within it. If the code isn't a model of the business domain, then what is it? If you're not intentionally modeling the domain, then what are you accidentally modeling instead? Even in the best systems, your code will reflect some aspects of the domain model well in some places, but not so well in others.
Consider this example: Your team is building an application that will support SaaS customers, and you're interested in the sign-up process. The story the team is playing says, "As a customer, I want to be able to sign up for a subscription so that I can use the service." You look at the code and find that the requisite method is in the "customer" class, which makes sense, but that it's named CreateCustomer.
Ouch.
Developers tend to think and talk in development terms, which naturally results in inadvertent models of how instead of what and why. This is common, and it's a tar pit, because developers tend to follow established patterns. What's more, once the true purpose of the code is obscured, it's unlikely that anyone will unearth it.
Yes, the functionality of the method named CreateCustomer does everything required to complete a customer signup, but the language it uses describes its own implementation, not the domain activity. Naming the method SignUpForSaaSSubscription would better reflect the actual domain activity and make the intention of the method clear.
At a trivial level, it's all about the names you use for things. At the level above that, it's about the way that you combine and activate things to produce business value. At the level above that, it's the causal and relationship (semantic) model that keeps everything cohesive, coherent, and aligned with the business. This alignment can't come from an implementation-focused model. You must use a domain model.
A business-applicable model doesn't have to be couched in DDD terms to be good. If your business model is naturally and fully described by a database operations create, read, update, and delete (CRUD) model, then that's good enough. It's the alignment that matters, and continuous alignment is the goal.
Once you've captured a useful piece of the business in the model, you have a framework on which to support multiple applications. It's not a framework in the literal, technical sense, but a framework in the sense that it can guide the thinking and construction of solutions sufficiently well. But this isn't a one-shot activity.
Striving for model-domain harmony never ends, as long as the business keeps changing. But that's alright, because DDD is a continuous process. It keeps the guardrails up, the feedback flowing, and the software on track with the business. DDD does this strategically, tactically, and philosophically.
DDD philosophy
DDD talks a lot about the ubiquitous language of a domain (also called the domain language). Ubiquity is a goal, a guide, and the central organizing theme. Everyone, technical and nontechnical, must speak the same language, use the same terms, and give the same names to the same concepts. If not, group understanding will be inaccurate, the resulting communications will be imprecise, learning will be fractured, and the software will decay over time. The definitive source of names, definitions, and descriptions is the subject matter expert (aka domain expert), not the software developers.
This quasi-Zen emphasis on pure definitions and unified communications, within specific boundaries, is the glue that holds it all together, the philosophical principle that forms the guardrails that keep everything else on track. The strategic, tactical, and technical aspects of DDD are intended to support and enforce this philosophy. You model the business in business terms (and model the domain in domain terms) and then protect that model from corruption in conversation, design, and implementation.
The strategic aspect of DDD aligns software development teams' efforts with the interests of the business. It helps when deciding what to focus on, usually by identifying one core domain. This may be a specific area of business or even a specific slice that's critical. The strategic focus keeps your major efforts devoted to what's most important to the business now. This prevents the sluggishness and paralysis of the everything-we-do-is-most-important blanket that often smothers software development efforts, while effectively accumulating corporate knowledge in the software.
The tactical, technical aspect of DDD guides the implementation process with the fundamental purpose of protecting the model from corruption. The patterns and architectural structures commonly associated with DDD (though not necessarily first invented or discovered by DDD) flow naturally from this constraint, to provide the requisite layers of protection.
Sadly, many developers, when first learning about DDD, scoop up the technical patterns and don't tarry long enough to absorb the philosophy or strategy. Using the patterns of DDD without adherence to the philosophy of DDD reduces the method to a cookie-cutter, mechanical approach to design that can create costly and unnecessary complexity. If you get the context boundaries wrong, it will be difficult to apply and maintain the code in spite of the otherwise desirable patterns. If the model in the code is lax about its use of domain language, it will rapidly lose alignment with the business.
In many ways this is why DDD is considered hard to do right: it takes a certain amount of self-discipline to adhere to the philosophy and requires another level of restraint to resist designing when you should be modeling. It also takes courage to keep asking "What does this really mean?" and "Why does this happen?"until the deeper model is uncovered. Finally, it requires patience to keep refining, refactoring, iterating, and accepting feedback until the model, the code, and the business coalesce into a cooperative synergy.
If you're building simple applications in a simple domain, your model will also be simple, and so shouldn't be excessively time-consuming to discover. That doesn't mean that crafting it will be easy, though. Above all, you must commit to learning about the business. Many developers only have eyes for gadgets, technology, and tools, while business-related things are regarded as irrelevant inconveniences. But you can't help the business develop its capabilities without understanding the business. There's no magic tool to Google the minds of the subject matter experts, and no mobile app will let you skip having those detailed conversations about how the business works.
A little DDD can go a long way. Even if you decide not to continue DDD practices past the initial model, or only go for a few iterations, you'll be able to make that decision from a position of knowledge, instead of guesses and wishes.
Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.
This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.
To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:
For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.
For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.
Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.
Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.
If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.
On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.
We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.
Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.
Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.
This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.
This site currently does not respond to Do Not Track signals.
Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.
This site is not directed to children under the age of 13.
Pearson may send or direct marketing communications to users, provided that
Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.
If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.
Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.
Pearson does not rent or sell personal information in exchange for any payment of money.
While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.
California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.
Pearson may disclose personal information, as follows:
This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.
Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.
Looked at one way, your digital product consists of code. However, look at it another way and it’s obviously far more than that. The code in your app, platform or website – essential though it may be – is just one part of a larger, more complex system, or “domain”. Your product’s domain is basically the subject area that your product addresses and/or operates within. It includes the user requirements the product aims to fulfil, the business goals it will contribute to, and the terminology used to describe and discuss it. The domain then influences more technical issues, such as programming languages, the devices and other hardware to be used, and of course, the programmed code, functions and features of the product itself. The more complex the product and its domain, the more important it is to include all elements of that domain in the design and development process.
When your design process is domain-driven, it incorporates a model of the domain in the process itself. A common approach is used by everyone involved in the product’s design and development, one that uses a common language and terminology, and a common understanding of just why the product is being built.
The concept of domain-driven design was first elaborated by Eric Evans, in his 2004 book, “Domain-Driven Design: Tackling Complexity in the Heart of Software”. Central to Evans’ book is the concept that not only do all those involved in the product’s design need a common language, that language should also be a fundamental part of the product to be built.
Put another way, domain-driven design is a system of collaboration, enabling technical and non-technical contributors (such as subject matter experts) to communicate and understand each other, to the ultimate benefit of the product being created.
One way to find clarity on the ingredients of DDD is to focus on the core terminology, as follows:
Domain-driven design is an ideal route to a coherent and consistent design process. However, while it is potentially extremely efficient, it may be too much for simpler digital products – a case of using a sledgehammer to crack a nut. DDD is best-suited to complex problems, or products that are expected to operate within and take account of a complex and varied business environment; i.e. numerous data sources, various interconnections between data, and multiple outputs.
Similarly, one of the goals of DDD is to bring the technical and business aspects of the design process together. Arguably, the more important the business goal which your digital product supports, the stronger the case for using a domain-driven approach.
Finally, with a large and varied design team and stakeholder group, the common language that results from being domain-driven helps ensure clear communication and discussion in an environment in which misunderstandings could be fatal to your digital product.
So far, we’ve talked about how DDD organizes and impacts the design process, facilitating more efficient working between people with different backgrounds and competences. But the domain-driven design approach can also be applied to your digital product’s code, its architecture…
The issue is that in a complex domain, or a complex product, different elements interact and therefore interrelate – make a change to a business rule as part of your ongoing maintenance and updating and you could find consequences in how your user interface or database function, for example. The answer is always to create and maintain simplicity. As with the use of subdomains as a way of breaking a complex domain into smaller problems, in terms of your coding structure, the DDD solution is to use a layered architecture to manage complexities. Each layer is cohesive and is dependent on (i.e. requires data from, or is impacted by) the layers below. Put another way, higher layers refer to lower layers, but not the other way around. Eric Evans’ book recommends four layers:
Your digital product may not need all four layers but if you’re taking a domain-driven design approach, the domain layer is an essential.
For complex applications, adopting a domain-driven approach offers the following benefits for your design process:
All that said, it must be acknowledged that DDD requires extensive domain expertise and input. This may sound obvious but it can result in a lengthier (and therefore more expensive) design process. For complex products, or products operating in a complex domain, DDD is absolutely the most effective and efficient approach (especially when combined with an Agile methodology, such as scrum) but for simpler scenarios, well, it’s back to that sledgehammer and nut analogy.
