Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
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 a recent entry, Phillip Calcado asks the question "What Is A Service?" and then goes on to describe how the answer to this lies with Domain Driven Design and ensuring that all stakeholders in an SOA development share the same understanding.
As the complexity of the real-life problems grows, it becomes obvious that in order to solve them, it is often necessary to combine multiple techniques. One example of a good symbiotic relationship is that between Service Oriented Architecture (SOA) and Domain Driven Design (DDD).
Many approaches to object oriented modeling tend not to scale well when the applications grow in size and complexity. Context Mapping technique can be used to manage the complexity in large software development projects. In this article, author Alberto Brandolini discusses the many sides of bounded contexts and how to use them to build a context map to support key decisions in a software project.
Domain driven design will help you build the core of an application, but then you still have to develop the presentation layer, duplicating the validation logic as you go. For internal applications where functionality really is more important than form, Naked Objects can be the answer. With proper annotation, Naked Objects can automatically generate a matching presentation layer in Java or .NET.
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.
At QCon San Francisco, 2008, Eric Evans answers questions about his recent activities and the evolution of DDD. During the interview he responds to questions about the relationship of DDD to usability, to FIT and FITnesse type testing, technology tools, and domain-specific languages. He also speaks about the DDD community as a whole.
In this interview, Greg Young talks about managing state transitions in a Domain-Driven Design project using two separate models, one for reading data from datastore and the other for write-only command operations. He also discussed Command Query Separation to keep the design cleaner and easier to test and maintain and the best practices that developers can use when working on DDD projects.
Domain Driven Design is a vision and approach for designing a domain model that reflects a deep understanding of the business domain. This book is a short, quickly-readable summary and introduction to the fundamentals of DDD; it does not introduce any new concepts; it attempts to concisely summarize the essence of what DDD is, drawing mostly Eric Evans' book, as well other sources since published such as Jimmy Nilsson's Applying Domain Driven Design, and various DDD discussion forums.
