Expanding on Eric Evans’ original book, Domain-Driven Design (DDD), Vaughn Vernon presents in his book “Implementing Domain-Driven Design” common sense DDD procedures through models from recognizable areas. Each principle is backed up by realistic Java examples-all applicable to C# developers and all content is supported by a single case study: the delivery of a large-scale Scrum-based SaaS system for a multi-tenant environment.
Carrying out Domain-Driven Design presents a hierarchical way to deal with understanding area driven plan (DDD) in a way that easily associates key examples to basic strategic programming instruments. Vaughn Vernon couples guided ways to deal with execution with present day designs, featuring the significance and benefit of focusing on the business domain while balancing technical considerations
Wikipedia defines domain-driven design (DDD) as “an approach to develop software for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following:
* Placing the project’s primary focus on the core domain and domain logic.
* Basing complex designs on a model of the domain.
* Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
This book is not just an introduction to the Domain-Driven Design world, but a very detailed (close to 600 pages) technical approach about what it takes to successfully implement DDD as a base for the software architecture of an organization. The book is well-structured. Each chapter starts with a roadmap and ends with a wrap-up. The content is a balanced mix of concept, discussion about the original DDD material by Eric Evans and examples, including some code listing that show how you implement the concepts in the software.
I will recommend the book Implementing Domain-Driven Design by Vaughn Vernon to every software architect and software developer concerned with the architecture and long term evolution of the applications that they develop.
Reference: Implementing Domain-Driven Design, Vaughn Vernon, Addison-Wesley
Quotes
We strive to produce quality in the software we develop. We achieve some quality by using tests to help us avoid delivering software with a fatal number of bugs. Yet, even if we could produce completely bug-free software, that in itself does not necessarily mean that a quality software model is designed. The software model – the way the software expresses the solution to the business goal being sought – could still suffer greatly. Delivering software with few defects is obviously good. Still, we can reach higher for a well-designed software model that explicitly reflects the intended business objective, and our work may even reach the level of great.
One of the worst disconnects of a business software development effort is seen in the gap between domain experts and software developers. Generally speaking, true domain experts are focused on delivering business value. On the other hand, software developers are typically drawn to technology and technical solutions to business problems. It’s not that software developers have wrong motivations; it’s just what tends to grab their attention. Even when software developers engage with domain experts, the collaboration is largely at a surface level, and the software that gets developed often results in a translation/ mapping between how the business thinks and operates and how the software developer interprets that. The resulting software generally does not reflect a recognizable realization of the mental model of the domain experts, or perhaps it does so only partially. Over time this disconnect becomes costly. The translation of domain knowledge into software is lost as developers transition to other projects or leave the company.
As you implement DDD, you will encounter challenges. So has everyone else who has succeeded at it. What are the common challenges and how do we justify using DDD as we face them? I will discuss the more common ones:
* Allowing for the time and effort required to create a Ubiquitous Language
* Involving domain experts at the outset and continuously with the project
* Changing the way developers think about solutions in their domain