Write code to build software to fulfill client needs and solve problems - the problem solving is the real goal here. Quite a learning curve as DDD is complexĪ big piece of DDD is solving problems via an understanding of client needs.
Lots of time spent figuring out the domain and subdomains.Many patterns that can be used in different projects.It simplifies design in a complex system and makes future extensions and maintenance far easier. However, where DDD is applicable, it is very helpful. Example: DDD would be overkill in an application that just needs CRUD (create, remove, update, delete) logic. However, it does encompass a number of patterns which can be applied to various situations. Keep in mind that technical complexity is different from domain complexity. It's most applicable in complex domains (as the name suggests), particularly when the client finds it difficult to communicate their needs to the developers. (Although I can't personally comment on that front, as I have yet to read the book)ĭDD is not a one-size-fits-all silver bullet. They're entirely different things.ĭDD was first introduced in Eric Evans's 2003 book Domain-Driven Design: Tackling Complexity in the Heart of Software, which many consider a must-read of software developers. For anyone as confused as I was, there's not really an equivalency there. Even though I know that TDD stands for Test-Driven Development and DDD stands for Domain-Driven Design, I had this weird equivalency in my mind before I really started looking into DDD. Firstly, I just want to point out something that I found confusing at first.