In some recent discussions with potential clients, they’ve told me that one of their goals for their project was to migrate to a DDD architecture. Though it’s clear the idea they were trying to get across, the idea of a DDD architecture doesn’t make sense.
The main idea behind DDD is in the name itself: Domain Driven Design. In applying DDD concepts, we are designing what our domain model will look like and how it will behave. We imagine the interactions among the pieces, what responsibilities the entities will have and what should be delegated to outside services, which entities belong to which aggregates, etc. We are deciding how best to implement our domain rules in code so our system is flexible and easily enhanced.
Architecture is deciding the proper infrastructure to properly manage all these pieces. DDD can be implemented using different types of architectures, such as a layers (2-tier, 3-tier, etc.), a functional architecture, CQRS, or even the Actor Model or Hexagonal Architectures. Each of these architectures has their sweet spot depending on the size and purpose of the system, the size and experience of the team, and deadlines or other time pressures. The most popular by far is a layered design, and when I hear people conflate DDD and architecture I assume this is the architecture they are talking about.
In the real world, this difference becomes significant when discussing deliverables. The output of a DDD design session is not an architectural diagram.
Hi, I’m Brad Irby. Since I began my career in Software Development 30 years ago, nearly every project I’ve worked on has been with existing code, not building from scratch. In working with companies like General Electric, Wells Fargo,and Bank of America, I have learned how to work with large legacy systems, and bring them up to date by injecting current development techniques into existing code. In fact I’ve done it so often, Addison Wesley ask me to write a book about it. Learn More