Implementing Domain Driven Design (IDDD) by Vaughn Vernon addresses an open secret in the software community: many more people want to do Domain Driven Design (DDD) than understand how to use it. Vernon tackles this issue by guiding his readers through DDD’s principles, illustrating the importance and correct execution for each one. By providing a myriad of teaching techniques such as code samples, rules of thumb, a case study that progresses throughout the book, and ‘good ole cowboy logic’, IDDD reaches a level of accessibility that enables even the uninitiated to achieve an excellent understanding of DDD.
Implementing Domain Driven Design, p. 99
Throughout his book, Vernon returns to the narrative of a fictional software team as it learns and implements DDD. In each chapter, the team becomes more proficient in applying different concepts, and their discussions detailing the pros and cons of their findings help the reader feel involved in their decisions. As the team’s design iterates and improves, they demonstrate the reality of having to embrace refactoring as a mechanism of understanding of their own domain. Through this highly relatable example of collaboration within the DDD process, one is able to safely experiment along with the case study team without having to actually take any risk of their own.
The sheer breadth of DDD is one of the common barriers to its adoption within an organization. Because of this, developers often choose to side-step the “big bang” approach and instead implement a new facet of DDD only as its need becomes clear within their domain. Vernon acknowledges this piecemeal approach to DDD and through relating his experience and his detailed examples, he is able to help the reader understand advantage of adopting a new concept right away as well as the disadvantages the team may face if they choose to implement the concept later. This pattern of presenting the various aspects of DDD allows the reader to make informed decisions about the maturation of their own domain without the need for actual trial and error.
Implementing Domain Driven Design, p. 457
Implementing Domain Driven Design represents a significant addition to the literature of Software Design in general and Domain Driven Design in particular. Vernon’s use of clear and useful examples delivered in an approachable, yet authoritative manner give the reader the confidence and knowledge they need to try DDD for themselves. Further increasing its relevance and usefulness, the practices outlined within IDDD dovetail with previous works in the realm of DDD, such as Eric Evans’ Domain Driven Design and Applying Domain Driven Design by Jimmy Nilsson, as well as reinforcing the tenants and practices of Object Oriented Design. Implementing Domain Driven Design, is a welcome and important addition to DDD literature and it will help any developer improve their design and collaboration skills … even if it isn’t their first rodeo.
InfoQ was able to reach Vaughn Vernon during the European leg of his IDDD Tour, our virtual interview follows:
InfoQ: Eric Evans’ work on Domain Driven Design is largely considered the gold standard for DDD’s definition and execution. Your book on Domain Driven Design is being published almost a decade later after Evan’s “Blue Book”. Why now?
If you look around I think you will find other books that treat DDD in one way or another. For example, Jimmy Nilsson's book followed Eric Evans' relatively soon. I think Jimmy had real vision with his book and his efforts did a lot to move the .NET community forward.
My book is different from the others in that it takes a case study approach and purposely shows the kinds of mistakes that are most commonly made with DDD, and then reveals how to fix the mistakes or how to avoid them altogether. This approach does at least two things. First, it clearly shows readers what to avoid by pointing out in advance the common pitfalls. One of the most difficult things to do as a consultant is to walk into a project where everyone is working hard, but struggling or failing, and point out where they are wrong. The team is naturally resistant to help because they get really married to their ideas, while insisting that their results should be better.
By the book pointing to the problems that a different team has had, it helps the reader drop any defensive posture. They can easily place themselves in the position of the failing team, but with anonymity. Second, the book provides clear guidance for implementing DDD in the safest way possible. By following this guidance, or these "rules of thumb," the teams approaching DDD have the best advice possible for success with DDD. It doesn't mean that you can never succeed if you decide to "break a rule" or two, but the rules should be followed until you understand the tradeoffs you'll face without them.
Why now? After working for a decade or two in our industry, who wouldn't agree that it's high time for a greater number to give serious attention to developing software as a craft? Of course there are some who will turn a blind eye, and the rest of us can only hope that we don't have to work with them on a project. Whenever that hope fails us, we sure want to know how to insulate ourselves from the mess by employing some sound DDD practices. So now is quite timely, I'd say.
InfoQ: Implementing DDD may take a while in an organization. What type of incremental benefits can be expected from a DDD effort?
I think that a team wanting to make incremental steps toward improved design can take a two-pronged approach. First of all, employ some strategic design by determining some high value that the business can benefit from. If you are working in an established company (not a startup), there is a high probability that the value will relate to a legacy/heritage system. Using Context Mapping and subdomain analysis will help you understand the problem space, leading to clear direction toward a solution. Once your team grasps the strategic direction, they can determine their Bounded Context where the new business value will be modeled.
However, one question generally arises. What is the best way to integrate with the legacy/heritage system? Here two primary approaches surface. If possible, you can have the legacy system publish some key Domain Events indicating what has occurred in that system. The new Bounded Context listens for and react to these significant Domain Events by carrying out some system behavior. I think you can usually find a way to publish some key Domain Events from the legacy system.
However, it may be impractical to give the legacy into a full Event-Driven Architecture. Therefore, it may also be necessary to create an additional means to exchange information between the legacy and the new system. I suggest looking at two strategic approaches, Open Host Service and Anti-Corruption Layer. There are other possibilities, but these two may be thought of as the "bread and butter" of DDD integration.
Note, however, that we are not making a big effort to improve the legacy. Instead we are only incrementally adding minimal hooks into the legacy; just enough to enable the new system. We may do some small re-writes, but experience shows that this must be held in check. Often times even small changes to the legacy can have significant ripples, and a great number of existing tests can fail widely if not held to a minimum. Trying to deal with all the ripple can be difficult, time consuming, and de-stabilizing.
Finally, the new Bounded Context could be modeled to a greater or lesser degree using DDD tactical design. There is a lot of value in using Aggregates, but there are some big challenges in achieving good Aggregate design. This is where a lot of attention needs to be given to the "rules of thumb" to ensure your success.
InfoQ: Some people may be intimidated about DDD because of its own language, apparent complexity, and nearly 600 page instruction manual. Is DDD really that hard to implement?
Yes and no. I think it depends most on your background. For those very familiar with good object-oriented design, many of the concepts will come somewhat naturally. On the other hand, those more familiar with a database-driven approach to development, with a myriad of getters and setters on an anemic model, it will require more discipline. This is mainly due to requiring a good amount of unlearning in addition to new learning. In this case what will matter the most is the developer's determination to change their approach.
My book will make it far easier for both groups to succeed in employing DDD. I must also make a shameless promotion of my training, which is called the IDDD Workshop. I have been holding a series of Workshops throughout Europe, which are nearly completed. I have a class in Denver, Colorado USA over July 22-25, 2013, which you can register for here
InfoQ: What type of resistance can a would-be DDDer face within an organization that needs his help? How can they overcome this resistance?
If you think you can change your entire enterprise, or some large part of it, with DDD, you will fail. You will fail whether you get the support of the business or not. Yet, you are very unlikely to get the support of the business with an idea as wild as changing some large part of your enterprise. To my mind, I think that the biggest mistake with DDD is when a determined group of developers and architects want to do too much, even as good as their intentions may be. It really frightens executive management to hear that a team wants to make major impacts on existing systems, perhaps even full rewrites of multiple systems. It's frightening not only for executive management: it's scary for anyone who understands the proper use of DDD, or just the complexity of succeeding at such an effort no matter what the approach. This situation is exacerbated when the DDD proponents make a lot of noise about their desired initiatives.
I think that the best way to avoid business resistance is to first find a small way to deliver real, significant business value in a new Bounded Context. For the first project it could be best to keep the scope relatively small, and just make sure you deliver regularly and stay within budget and on time. It's not like you can do this as a "skunk works" project, because you will need to draw a good bit of mind share from at least one domain expert. While you might be able to kick off a project on the down low, it probably can't operate that way for long. So plan to make a little impact as possible, and to keep expectations reasonable.
This mostly means that you will have to keep your own expectations and those of other developers under control. This is good training in thinking as the business thinks, which is quite important to implementing DDD in the way it should be.Don't make a lot of noise. Fly below the radar and just deliver. Earn respect and trust. After you deliver on a project or two, which leads to recognizable of business value, you'll then be in a better position to champion DDD based on your successes and your clear understanding of how it should and should not be used.
InfoQ: Ultimately, are all verticals good candidates for DDD? Can it be that a portion of a system can maintain its own level of complexity as the rest of the system's complexity increases?
The best place to use DDD is to address the most complex areas of your business and the ones that will yield the greatest business value. That generally means that some technology areas of the business don't deserve the DDD investment. That said, it doesn't mean that the use of sound software development principles, possibly even some based on DDD, shouldn’t be employed even in less demanding areas. What I mean is: because a system is not considered strategically important doesn’t mean that it should not be poorly implemented. Even generic and supporting software is essential to the overall operation of the end-to-end solution. However, you simply won't need to engage domain experts to the same degree as you will with a true Core Domain.
What sometimes surprises a team is that a system or subsystem that they never thought could be a Core Domain becomes one in time or at least plays an integral role in a new core initiative. Does that mean that you should try to anticipate the likelihood of this happening and model early on as if the system will finally need a DDD investment? I don't think that's wise. Yet, I would still say that you should allow your team to develop the best software possible even if they are not engaging regularly with domain experts. The better designed any system is, the easier it will be to evolve and maintain, and to extend if the time arrives to give it a more significant role than it once had.
I think the main point here is, know when and how to use DDD correctly, but don't consider a DDD non-starter to be an area to allow for poor software quality. That would simply be an irresponsible move.
One more word of advice is in order. Even a system modeled without DDD could still publish some important Domain Events or provide an Open Host Service as part of its service-level contract. Remember that even a weary legacy system could be enhanced to a minimal degree to publish Domain Events, so it's not like this should be considered an earth shattering step. This doesn't need a deep DDD investment because you can simply work out with one or more teams the Domain Events or API that they need in order to exchange information with your system. If your contract becomes an important part of the overall enterprise you may get to the point of creating an organizational Published Language, another important component of DDD strategic design.
You can see how the Identity and Access Context as part of my book's sample models takes this approach. The Identity and Access context is considered a Generic Subdomain, and doesn't get a DDD investment. Still, it is well designed, publishes important Domain Events, and provides an Open Host Service to allow other systems--DDD Core Domains--to integrate with it.
InfoQ: If a would-be DDD-er wanted to try DDD to help improve their product, with which concepts would you recommend them starting?
There is significant benefits in examining the problem space by using Contexts Maps and Subdomains, and identifying the new Bounded Context that is a Core Domain. You will find that Domain Events and Aggregates will play a major role in tactical design. Where possible, lean toward using Value Objects rather than Entities. Any time you can take the choice of immutability and side-effect-free functionality, you will likely save yourself a lot of problems.
You can see how to use various strategic and tactical modeling techniques by examining the book's sample models, both in Java and C#:
InfoQ: There are a lot of relatively new ideas gaining momentum in mainstream software development lately: DDD, Event Sourcing, NoSQL, and functional programming to name a few. DDD seems to play nicely with all of these concepts. Where do you think this momentum will take us?
The principles of the DDD approach can be used for a long time, and with various technologies, patterns, styles, and idiomatic influences. Thus, the simple answer is that I think DDD can be used for the foreseeable future. It seems to me that Event Sourcing as well as NoSQL are a matter of fact. Experience is being gained around using DDD with functional programming, and probably more so that functional programming is actually being used.
One architectural style that you don't mention is Actor Model. I am personally doing work in developing experience and tools around the use of Actor Model with DDD. In a functional programming environment this may translate to the Agent Model rather than Actor, but in both models there is an emphasis on message passing, non-blocking concurrency, that is highly distributed. This is one important way in which we will achieve squeezing more out of our expanding number of cores, but ones that are delivering less overall leaps in speed on individual processors. The basic ideas of Actor Model greatly simplifies our ability to comprehend and use concurrency and distribution.
If you'd like to try out the Actor Model you can find my experimental project here
You can also try out a full-blown Actor system using the Akka project for Scala or Java. If you are working on .NET you can try out Microsoft's ActorFX.
About the Book Author
Vaughn Vernon is a veteran software craftsman with more than twenty-five years of experience in software design, development, and architecture. He is a thought leader in simplifying software design and implementation using innovative methods. He has been programming with object-oriented languages since the 1980s and applying the tenets of Domain-Driven Design since his Smalltalk domain modeling days in the early 1990s. His experience spans a wide range of business domains, including aerospace, environmental, geospatial, insurance, medical and health care, and telecommunications. He has also succeeded in technical endeavors, creating reusable frameworks, libraries, and implementation acceleration tools. He consults and speaks internationally and has taught his Implementing Domain-Driven Design classes on multiple continents. You can read more about his latest efforts on his blog and follow him on Twitter here: @VaughnVernon