Domain Driven Design

Domain Driven Design

What is Domain-Driven Design?

Over the last decade or two, the philosophy of Domain-Driven Design, or DDD for short, has developed as an undercurrent in the object community. The premise of DDD is two-fold:

  • For most software projects, the primary focus should be on the domain and domain logic
  • Complex domain designs should be based on a model.
Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

To accomplish that goal, teams need an extensive set of design practices, techniques and principles. Refining and applying these techniques will be the subject of discussion for this site, generally starting from the language of patterns laid out in Domain-Driven Design, by Eric Evans.

Source: What is DDD

The challenge of Complexity

Of course many things can steer a project off its course: bureaucracy, unclear objectives, lack of resources, to name a few, but it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, the software can no longer be understood well enough to be easily changed or extended. By contrast, a good design can make opportunities out of those complex features.

Some of these design factors are technological, and a great deal of effort has gone into the design of networks, databases, and other technical dimension of software. Books have been written about how to solve these problems. Developers have cultivated their skills.

Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won’t matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software.

Source: What is DDD

The TigerTeam approach to DDD

Before we recommend an approach we also assess that the approach is applicable. Domain Driven Design is very suited for semi-large to large applications/solutions with complex logic that changes often. For smaller applications the introduction of DDD will typically introduce an overhead that often cannot be justified.

As an inspiration You can watch this free video from a recent talk on SOA, DDD, EDA and CQRS that we gave at IDDD Tour 2013 in Copenhagen.

 
Comments

No comments yet.

Leave a Reply