Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy

FINALLY! A difficult topic, eloquently decoposed and practical. Not another dry DDD read!
I just got the kindle version of the book and I have to say, I absolutely loved it! By far the best I’ve read on the topic overall, and not a dry read like just about every other book on the topic. It really realigns the design thought process with the business while… ahem… actually including the business, in true DDD fashion. It also really brings a lot of ideas together from the the most popular sources out there like Eric Evans, Martin Fowler, Chris Richardson, Greg Young, and many more, so this is coming from a very inspired place and will not giving that feeling like you’re being preached at.It provides real-life, usable heuristics, i.e. when to use the patterns, when to avoid them, when and how to change your mind about your decision later as the business evolves which I think has been a real sticking point for many engineers and architects that have considered DDD in the past. It even gives you a flow chart to use as a starting point on choosing which pattern to use in different areas of your system. For example, the area of the system I work in at my company would almost never use the domain model (i.e. the aggregate pattern, etc.) because most of what we build are supporting subdomains which support generic subdomains where simpler patterns are better suited for business logic. I’ve mostly known this, but this book has helped me articulate it so much better and I know that will help me get my organization aligned. It even extends these classifications to help you decide exactly where to put your people (offshore/contractor teams vs. FTEs vs. rock stars), and most importanly, in terms that even your business leadership should understand, and hey, that means they’ll be far more likely to support you in the way you need them because now it’s far clearer how that’s going to benefit them and less like you’re just being a diva hah!This book is mostly non-technical but there are some code samples that are just complete enough to articulate and idea. In other words, this book is focused on learning learning DDD __principles__ moreso than learning the patterns you’d implement in your code. In my opinion this is the most important part because while DDD comes with a couple ceremonies (e.g. Event Storming), it is mostly a structured frame of mind that keeps you in lock-step with the business rather than just churning code. This should be required reading for all software architects and leaders in the field! Even if you’re not planning on ever attempting it.At the end, in the appendix, there is a case study where Vlad pulls all the principles outlined in the book by sharing his personal experience with DDD starting off as a novice practitioner and stumbling around making every mistake there is to make, learning from it, and evolving the understanding; encountering the reason for each DDD principle along the way. Enlightening, really.That said, I’d love to see a follow-up that leans more into the specifics of a real code base in practice, and in C# for once. With how well Vladik articulates this subject (which is very approachable), I think something like that between this book and something like I’m suggesting coming from him could really inspire more growth of this community of practitioners.Thank you so much for writing this!

Simplified version of “Implementing Domain Driven Design”
I’d give this 4.5/5 if I could; probably the best introduction to DDD I’ve read. This reads like a slimmed-down, simplified version of Vernon’s “Implementing Domain Driven Design” which is much too complicated to serve as an introduction. I docked 1 (half if I could) star because the author makes some factual errors and lackluster stylistic choices that would only bite you if done on a large scale project. But since these errors don’t detract from the overall conclusions.

Excellent 300-page DDD Primer
Vlad Khononov’s “Learning Domain-Driven Design” clearly explains how DDD helps design software solutions aligned to business strategy in 300 pages, a rare find in the DDD literature.I particularly appreciated that Vlad is so well-connected to our industry, as demonstrated in Part IV, which discusses DDD’s relationship with microservices, event-driven architecture, and data mesh.Now that I have read it cover-to-cover, I can easily say it was one the best software-related books out of the 20 or so that I have read in 2021.If you appreciate authors that create tight storylines with proper information density, then Vlad Khononov should be on your reading list.

A must read for Architects and Engineers
Vlad does a masterful job of explaining the concepts of Domain Driven Design providing valuable real world examples that help the reader understand the reasoning behind it and it’s implementation. Thank you Vlad!

Bought the book looking at the ratings given by others. This book definitely exceeded my expectations in explaining domain-driven design and architectural patterns. Highly recommend this book.

A well structured, practical and experienced-based introduction to Domain Driven Design, with something for new comers and even ‘seasoned’ DDD practitioners.For newcomers to DDD this *is* the book you’ve been looking for:- easy to digest, Vladik takes you on a journey that shows you the ‘why’ not just the ‘how’- explains key patterns and approaches in a human readable and (importantly) relatable format- gives you “just enough” to make the right decisions, at the right time, without bombarding you with tons of detailed code, that depending on your implementation, may or may not be useful.The inclusion of decision trees and design heuristics that account for the evolution of a system, and outline how the various patterns apply/ evolve, is incredibly useful – all with emphasis on using the right patterns for the right reasons, and not over complicating your solution.Compared to the blue and red books, this is a much easier introduction to many of the core concepts and patterns from DDD (as your knowledge/ understanding grows you’ll still want those books, but this book is a fantastic onramp to the depths of detail the blue and red books contain).For those that have practiced DDD for some time, this book represents an up-to-date “pocket reference” (by DDD book standards!), reflecting:- field-tested heuristics and decision trees to speed-up decision making- how patterns and approaches (such as Domain event publishing) have evolved over time- how Event Storming can speed up discovery, and design- the influence of DDD on data, and the obvious value/ importance of Data Mesh, now that you are designing with context in mind.Highly recommended.

I have the feeling the author doesn’t stand 100% behind the DDD he’s trying to explain.Let me give you some examples:Author presents DDD theory explaining why it’s important to use DDD. In a late chapter he tells the reader basically to stay practical and avoid DDD when no need to use.Also, author extensively writes about Ubiquitous language, only then to summarize “The use of ubiquitous language is the cornerstone of DDD (…) Luckily, this practice is so trivial that it’s borderline common sense.”If so, why write a book then?