Domain-Driven Design: The Good And The Challenging - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Software // Information Management
09:30 AM
Dino Esposito
Dino Esposito

Domain-Driven Design: The Good And The Challenging

Ten years after its introduction, DDD has proven to be optimal for certain projects -- especially complex ones -- when proper care is applied to the right practices.

About a decade ago, Eric Evans presented domain-driven design (DDD) as a new approach to software development in his popular book, Domain-Driven Design: Tackling Complexity in the Heart of Software.

At first, DDD sounded like quite a promising approach, an extremely alluring one for developers working on complex projects. In DDD, once you understand the business domain your software is to address, all you need to do is build a layered architecture where the business logic is split into two distinct modules: core domain logic (which is invariant to use cases) and the application logic (which is the implementation of use cases).

DDD has an analytical portion made of artifacts such as ubiquitous language, bounded contexts, and context mapping; and it has a strategic part made up of aspects strictly related to the supporting software architecture and implementation. The popular rich domain model is just one of many other possible supporting architectures. (A system based on a rich domain model is not inherently better than a plain CRUD system as long as both systems fulfill requirements. The complexity of software stems primarily from the complexity of the underlying business problem.)

The scenario for which DDD provides invaluable help is understanding the intricacies of the business domain. The name of the approach therefore couldn't be more appropriate: domain-driven design. In terms of ROI, the analytical part of DDD is greater than that of the supporting architecture. DDD's ubiquitous language gives a method to learn about key terms -- nouns, verbs, adverbs -- used in the business by business experts. By building such a vocabulary, architects and developers can detect when, even within the same company, the language changes and the same term is used to mean different things or to refer to different aggregates of data.

Such a case forms a bounded context -- an area of the final system that exists on its own, much like a black box connected to the rest of the system. Context mapping is the graph that connects contexts together. Each context has its own language, an independent implementation, and an interface to talk to other bounded contexts. The entire system results from the composition of bounded contexts. The ultimate purpose of DDD is having bounded contexts emerge clearly and unequivocally out of gathered requirements.

Read the rest of this article on Dr. Dobb's.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

IT Leadership: 10 Ways to Unleash Enterprise Innovation
Lisa Morgan, Freelance Writer,  6/8/2021
Preparing for the Upcoming Quantum Computing Revolution
John Edwards, Technology Journalist & Author,  6/3/2021
How SolarWinds Changed Cybersecurity Leadership's Priorities
Jessica Davis, Senior Editor, Enterprise Apps,  5/26/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Planning Your Digital Transformation Roadmap
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
Flash Poll