Introduction
Software engineering is hard. How hard? Enough that approximately 70% of software projects are not successfully delivered on time, on budget, or according to the client’s requirements. In other words, the vast majority of projects fail. This issue is so deep and widespread that we even have a term for it: the software crisis.
Many studies have been conducted to investigate the reasons for this crisis.1 Although researchers have not been able to pinpoint a single cause, most of their findings share a common theme: communication. Communication issues can manifest themselves in different ways; for example, unclear requirements, uncertain project goals, or ineffective coordination of effort between teams.
Over the years, the software engineering industry has tried to improve inter- and intra-team communication by introducing new communication opportunities, processes, and mediums. Unfortunately, the success rates of our projects didn’t change much.
Domain-driven design (DDD) proposes to attack the software crisis and communication issues from a different angle.
What Is Domain-Driven Design?
DDD is a methodology that covers the whole software development lifecycle, from gathering requirements to low-level design. Its core premise is that to build better software, we have to align its design with the business’s domain, needs, and strategy. That’s where the name comes from: (business) domain-driven (software) design.
DDD proposes to align business and technical concerns ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access