“With Implementing Domain-Driven Design, Vaughn has made an important contribution not only to the literature of the Domain-Driven Design community, but also to the literature of the broader enterprise application architecture field. In key chapters on Architecture and Repositories, for example, Vaughn shows how DDD fits with the expanding array of architecture styles and persistence technologies for enterprise applications — including SOA and REST, NoSQL and data grids — that has emerged in the decade since Eric Evans’ seminal book was first published. And, fittingly, Vaughn illuminates the blocking and tackling of DDD — the implementation of entities, value objects, aggregates, services, events, factories, and repositories — with plentiful examples and valuable insights drawn from decades of practical experience. In a word, I would describe this book as thorough. For software developers of all experience levels looking to improve their results, and design and implement domain-driven enterprise applications consistently with the best current state of professional practice, Implementing Domain-Driven Design will impart a treasure trove of knowledge hard won within the DDD and enterprise application architecture communities over the last couple decades.”
— Randy Stafford, Architect At-Large, Oracle Coherence Product Development
Most developers have had to change the way they think in order to properly apply DDD. We developers are technical thinkers. Technical solutions come easy for us. It’s not that thinking technically is bad. It’s just that there are times when thinking less technically is better. If it’s been our habit to practice software development only in technical ways for years, perhaps now would be a good time to consider a new way of thinking. Developing the Ubiquitous Language of your domain is the best place to start.
Cowboy Logic
LB: “That fella’s boots are too small. If he don’t find himself another pair, his toes are gonna hurt.”
AJ: “Yep. If you don’t listen, you’re gonna have to feel.”
How to Involve Domain Experts in Your Project
Coffee. Use that Ubiquitous Language:
“Hi, Sally, I got you a tall half-skinny half-one-percent extra-hot split-quad-shot latte with whip. Do you have a few minutes to talk about . . . ?”
Learn to use the Ubiquitous Language of C-Level management: “. . . profits . . . revenues . . . competitive edge . . . market domination.” Seriously.
Hockey tickets
There’s another level of thought that is required with DDD that goes beyond concept naming. When we model a domain through software, we are required to give careful thought to which model objects do what. It’s about designing the behaviors of objects. Yes, we want the behaviors to be named properly to convey the essence of the Ubiquitous Language. But what an object does by means of a specific behavior must be considered. This is a level of effort that goes beyond creating attributes on a class and exposing getters and setters publicly to clients of the model.
So, I hope you enjoyed it. Happy Coding👨💻
References
[Vaughn Vernon],“Implementing Domain-Driven Design”
Top comments (0)