Domain Driven Design (DDD) is about evolving a shared model of the domain letting the domain model drive the design. BDD is about establishing a shared understanding of “done” working from the outside in until you get there. DDD enables the use of BDD effectively creating software and BDD helps structure the conversations for DDD.
In this presentation held during OOPSLA 2008, Rebecca Wirfs-Brock reviews various forms of driven development in order to understand the principles and values of several design practices used today. By comparing them, a designer will get a broader view over design and will better understand which design practice is more appropriate for him.
Scott Shaw, Director of Services at ThoughtWorks, and Martin Fowler, Chief Scientist at ThoughtWorks, talk about the need for a new relationship between the business department and the IT department. Studies have constantly shown that the main culprit for unsuccessful projects lies in miscommunication between the business people and the IT ones.
In this presentation filmed during QCon London 2007, Martin Fowler and Dan North talk about the communication gap existing between the developers and the customers or users. Closing this gap is extremely important in order to create successful software.
In DDD, the "ubiquitous language" is central, but it's richness and fluency is hard to render in the object-oriented medium. Domain-specific languages hold out the prospect of to express models and application logic in far better suited language. In this presentation, Eric Evans talks about how DDD and DSLs works together in complex business applications.
This talk introduces two broad principles for strategic design. 'Context mapping' addresses the fact that different groups model differently. 'Core domain' distills a shared vision of the system's "core domain" and provides a systematic guide to when "good enough" is good enough versus when to push for excellence.
This talk will outline some of the foundations of domain-driven design:How models are chosen and evaluated;How multiple models coexist;How the patterns help avoid the common pitfalls, such as overly interconnected models;How developers and domain experts together in a DDD team engage in deeper exploration of their problem domain and make that understanding tangible as a practical software design.