- File Size: 41043 KB
- Print Length: 656 pages
- Simultaneous Device Usage: Up to 5 simultaneous devices, per publisher limits
- Publisher: Addison-Wesley Professional; 1 edition (February 6, 2013)
- Publication Date: February 6, 2013
- Sold by: Amazon.com Services LLC
- Language: English
- ASIN: B00BCLEBN8
- Text-to-Speech: Enabled
- Word Wise: Not Enabled
- Lending: Not Enabled
- Amazon Best Sellers Rank: #135,809 Paid in Kindle Store (See Top 100 Paid in Kindle Store)
Implementing Domain-Driven Design 1st Edition, Kindle Edition
Use the Amazon App to scan ISBNs and compare prices.
All books, all the time
Find reading recommendations, author interviews, editors' picks, and more at the Amazon Book Review. Learn more.
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Customers who bought this item also bought
About the Author
--This text refers to the hardcover edition.
—Randy Stafford, Architect At-Large, Oracle Coherence Product Development
“Domain-Driven Design is a powerful set of thinking tools that can have a profound impact on how effective a team can be at building software-intensive systems. The thing is that many developers got lost at times when applying these thinking tools and really needed more concrete guidance. In this book, Vaughn provides the missing links between theory and practice. In addition to shedding light on many of the misunderstood elements of DDD, Vaughn also connects new concepts like Command/Query Responsibility Segregation and Event Sourcing that many advanced DDD practitioners have used with great success. This book is a must-read for anybody looking to put DDD into practice.”
—Udi Dahan, Founder of NServiceBus
“For years, developers struggling to practice Domain-Driven Design have been wishing for more practical help in actually implementing DDD. Vaughn did an excellent job in closing the gap between theory and practice with a complete implementation reference. He paints a vivid picture of what it is like to do DDD in a contemporary project, and provides plenty of practical advice on how to approach and solve typical challenges occurring in a project life cycle.”
— Alberto Brandolini, DDD Instructor, Certified by Eric Evans and Domain Language, Inc.
“Implementing Domain-Driven Design does a remarkable thing: it takes a sophisticated and substantial topic area in DDD and presents it clearly, with nuance, fun and finesse. This book is written in an engaging and friendly style, like a trusted advisor giving you expert counsel on how to accomplish what is most important. By the time you finish the book you will be able to begin applying all the important concepts of DDD, and then some. As I read, I found myself highlighting many sections . . . I will be referring back to it, and recommending it, often.”
— Paul Rayner, Principal Consultant & Owner, Virtual Genius, LLC., DDD Instructor, Certified by Eric Evans and Domain Language, Inc., DDD Denver Founder and Co-leader
“One important part of the DDD classes I teach is discussing how to put all the ideas and pieces together into a full blown working implementation. With this book, the DDD community now has a comprehensive reference that addresses this in detail. Implementing Domain-Driven Design deals with all aspects of building a system using DDD, from getting the small details right to keeping track of the big picture. This is a great reference and an excellent companion to Eric Evans seminal DDD book.”
— Patrik Fredriksson, DDD Instructor, Certified by Eric Evans and Domain Language, Inc.
“If you care about software craftsmanship—and you should—then Domain-Driven Design is a crucial skill set to master and Implementing Domain-Driven Design is the fast path to success. IDDD offers a highly readable yet rigorous discussion of DDD’s strategic and tactical patterns that enables developers to move immediately from understanding to action. Tomorrow’s business software will benefit from the clear guidance provided by this book.”
—Dave Muirhead, Principal Consultant, Blue River Systems Group
“There’s theory and practice around DDD that every developer needs to know, and this is the missing piece of the puzzle that puts it all together. Highly recommended!”
—Rickard Öberg, Java Champion and Developer at Neo Technology
“In IDDD, Vaughn takes a top-down approach to DDD, bringing strategic patterns such as bounded context and context maps to the fore, with the building block patterns of entities, values and services tackled later. His book uses a case study throughout, and to get the most out of it you’ll need to spend time grokking that case study. But if you do you’ll be able to see the value of applying DDD to a complex domain; the frequent sidenotes, diagrams, tables, and code all help illustrate the main points. So if you want to build a solid DDD system employing the architectural styles most commonly in use today, Vaughn’s book comes recommended.”
—Dan Haywood, author of Domain-Driven Design with Naked Objects
“This book employs a top-down approach to understanding DDD in a way that fluently connects strategic patterns to lower level tactical constraints. Theory is coupled with guided approaches to implementation within modern architectural styles. Throughout the book, Vaughn highlights the importance and value of focusing on the business domain all while balancing technical considerations. As a result, the role of DDD, as well as what it does and perhaps more importantly doesn’t imply, become ostensibly clear. Many a time, my team and I would be at odds with the friction encountered in applying DDD. With Implementing Domain-Driven Design as our luminous guide we were able to overcome those challenges and translate our efforts into immediate business value.”
—Lev Gorodinski, Principal Architect, DrillSpot.com--This text refers to the hardcover edition.
Would you like to tell us about a lower price?
There was a problem filtering reviews right now. Please try again later.
There's enough good material in the book for me to convince myself I needed to plow through it to the end; the writing was such that I had to force myself to do it. I'd really like to read a copy of this that had had the benefit of a good editor. It was verbose, and tended to belabor points that I thought had been pretty clearly conveyed in a few pages, so it took a while to get through it.
It's a fairly thorough overview of the DDD space, and I think it filled in some things I didn't get from Evans earlier book. I do question some of the breezy assertions that it was almost always best to opt for the purety of the model over implementation concerns, particularly around doing implementations on top of RDBMS persistence.
I think it was worth the read, but in comparison to other technical books I've read (and I read a lot of them), it was a lot more work to get through the prose than I think it needed to be.
This book explains DDD concepts on well-chosen domain problem - agile and SCRUM. Reader (who is very likely to have at least some experience with SCRUM) is going to feel comfortable with most of the examples that this book provides.
Another huge plus is that author stays pragmatic. Author knows that DDD touches lot of 'theoretical' concepts, so he often mentions real-world situations and advises how to compromise certain situations - how can be DDD fully or not-so-fully utilised within your business. If you're afraid of 'too many abstractions' then don't be - peek into table of contents and you will see that author explains DDD on very real and quite recent technologies/buzzwords like REST, CQCS, Hexagonal Architecture etc. Author also assumes that reader is rather new to the whole DDD thing and patiently explains things you were 'afraid to ask', like "What's the difference between DAO and Repository?", "Is it OK to put fine-grained queries to DAO and return Value Objects?" etc.
On the other hand - what's not so great about this book is its verbosity. I don't mind repeating important concepts (redundancy can be useful as we know it from Head First books for example), but I often felt like reading a novel. If I wanted to read a novel, I would buy a novel. Technical books should be brief and precise. I had the feeling that it was happening too often that author went too deep into the problem and I simply got bored way too many times. I think the useful content of this book would comfortably fit into 60% of its length.
Last, but not least, I'd like to exalt the book structure and formatting which was really good. Even Kindle versions gets properly formatted source code, which (unfortunately) still isn't standard.
Although first few chapters were a bit hard to understand (I did not read original DDD book of 2003) - later chapters were clarifying terms not understood before incrementally
I learned a lot from this book!
Top international reviews
My team started reading this book together. Everybody agrees it is too verbose. I intend to finish it but only after a break - a shame, since the content is good.
I think the first few chapters about bounded contexts etc. are well positioned early in the book. The chapter on aggregates is very late in the book and it would benefit from a brief introduction to the idea earlier on. I'd encourage readers to jump around when they come across terms they don't know yet.
A commonplace observation, but like most of these books I have to say the parts I understood by far the best are the areas where I already knew the content from experience. So I feel I'll need to re-read this to get most of the benefit - but given the verbosity issue I'll probably read Evans' book instead. Some books do manage to rise above this problem to some extent, but I didn't feel that with this book.
All up the book covers a lot of ground and personally I think the author did an excellent job. If there was anything I would change it'd be making a reference to my favourite IDE and tools throughout, but I acknowledge that doing so would more than likely drive the Java readers mad so I don't fault the author for his choice.
In a lot of ways DDD can be seen as a tool for architects and developers and I personally felt better equipped to use my DDD tools and skillset out in the real world after having read "Implementing Domain-Driven Design" by Vaughn Vernon.
All of the salient points are covered but the examples are very ‘Enterprise Java’ so very imperative, lots of boilerplate, etc. and although I tend to agree with many of the principles of DDD, this approach to implementing them makes me feel a bit sick in my mouth.
I've only started reading it and so far has been fairly easy to get into. It was recommended by a senior developer within the company and I trust his views.
Also recommended 1. Enterprise design patterns, Martin Fowler; 2. Implementing domain driven design, Vaugn; 3. Domain Driven design, Eric Evans; 4. Anything by Greg Young around CQRS. Only read the third one after the second - its a bit heavy going.
Dann verließ er die Firma und ich zwang mich dieses Buch von Vaughn zu lesen, fast von Deckel zu Deckel.
In vielerlei Hinsicht öffnete es mir die Augen was wirklich wichtig ist in der Softwareentwicklung und in welche Bereiche man seine Energie stecken sollte. Zum anderen waren viele andere Konzepte und Ideen auf einmal viel greifbarer für mich, zB das Agile Manifesto oder die Idee hinter Behavior Driven Development, sogar Clean Code von Uncle Bob verstand ich auf einmal aus einer ganz anderen Sicht.
Ich finde die Tactical Patterns werden in diesem Buch einem sehr gut und anschaulich nahegebracht. Entgegen anderer Rezensionen finde ich es nicht schlimm die Tactical Patterns anhand von Code zu veranschaulichen. Für mich ist es das Buch dadurch nicht weniger zeitlos. Schwieriger greifbar finde ich die Erklärungen zu den meiner Meinung nach wichtigeren Strategical Patterns. Ich musste wirklich sehr langsam, konzentriert und genau und zum Teil mehrfach lesen um die Essenz zu begreifen.
Ich glaube durch dieses Werk habe ich einen ersten guten Einstieg und Einblick in das Thema DDD erhalten. Das Buch erklärt gerade in Hinblick auf das strategische Design gut die Konzepte und Ideen, behandelt aber nicht die Fragen, wie ich von A nach B komme. Ich hätte mir Verweise auf Methodiken gewünscht, wie zB Event Storming oder Three Amigo Sessions. Spätestens hier wird einem klar, dass es ohne weitere Literatur, Blogs und vor allem Diskussionen nicht weitergeht. Aber das Buch bildet meiner Meinung nach eine sehr solide Gesprächsgrundlage.
As others have noted you'll have to read a lot for little information. I totally agree and here are a couple of examples I have at hand:
[p. 402 - Repositories - Introduction]
"there are circumstances under which a collection-oriented design will work for you, and circumstances when it is best to use a presistence-oriented design. I first discuss when to use and how to create a collection-oriented Repository and follow that with a treatment of persistence-oriented ones.";
[same page, two paragraph below under the title Collection-Oriented Repositories]
"it's possible that it won't work for you. If your persistence mechanism prevents you or hampers your ability to design with a collection perspective, see the following subsection. I address the conditions under which I think collection-oriented design works best. To do so I need to estalish some fundational background."
Other times I found the almost exact same text presented twice on the same page:
[p. 302 - in the highlighted section titled "Be Careful about What the Event handler Does"]
"Remember, the Application Service controls the transaction. Don't use the Event notification to modify a second Aggregate instance. That breaks a rule of thumb to modify one Aggregate instance per transaction."
[and immediately after]
"One thing the subscriber should not do is get another Aggregate instance and execute modifying command behavior on it. This would violate the modify-single-aggregate-instance-in-single-transaction rule of thumb, as discussed in Aggregates."
I found it really upsetting. Especially as I had to filter through all this zero-value chatter, to learn something about the topic. This is not the only case where information was obscured under heaps of words. My guess is that the book could have been at least 2/3 of its size if the author had wrote it in a concise form. Considering it's a book for professionals I find it unacceptable.
There is also another aspect I disliked about the writing style, which is the use of double negation, and more in general a wrong-example-first presentation style.
An example of a sentence using double negation is at p. 64: "Of course, there is no rule that says that more meaning cannot be added to these names. That's a decision of your team".
How does that feel compared to this: of course, your team might want to add more meaning to these names.
Regarding the "wrong-example-first" style, what I mean is that the DDD principles are often (if not always) introduced with a bad-design example first. Followed by chatter and then the good-example. While I think it is useful to compare good and bad designs, I found it tiring to read the description of a bad-example while waiting for so much anticipated concepts of DDD to be presented. I thought I was supposed to keep the bad-example in mind in order to relate it with what was about to follow. I thought that would give me a better understanding. But in the end I found it more tiring than useful.
In retrospective I can definitely say that's not the way I like to learn. Imagining I wanted to learn how to play tennis I'd prefer to be shown how to move properly before being warned about pitfalls and typical errors. Likewise I would have preferred to be presented a clear, as simple as possible, concept to be memorized and then used as an anchor to understand the dangers I could face departing from it.
I'm not sure what the average learning style of the target reader is, perhaps for someone else reading what-not-to-do first works better.
I've been also deluded by the examples inspired by "real-life", as found the stories about this hypothetical team entering the world of DDD just a boring self-affirming narrative in third-person of what the team did wrong initially and how happy they where when they finally embraced the tenets of DDD. I was hoping to read some typical QA dialogs bewteen developers and business domain experts. I was hoping to be presented typical cues to look for in a dialog indicating an DDD pattern might be appropriate.
Perhaps that's expecting too much, yet I did not gain much insight reading the story of the SaasOvation team and this contributes to my bad impression about the book.
To conclude, I think the intention behind this this book is good. I appreciated the emphasis on the importance of strategic design versus simplistic adoption of tactical patterns. I guess the author loves and knows how to properly apply DDD principles in real life, and I think he should consider to rewrite it.
To the reader looking for an introduction to DDD, I'd say: look elsewhere.
I've found a few reviews about Evan's seminal book saying it's very verbose as well, and new concepts emerged after its publication are not covered, so perhaps not that one either.
== UPDATE 7 Jun 2015 ==
While writing this review I noticed another book titled "Patterns, Principles and Practices of Domain-Driven Design" [http://www.amazon.co.uk/dp/1118714709] . I'm not affiliated with the author or anything related with that book. I was so frustrated with "Implementing, Domain-Driven Design" I thought I had better find something else to read.
The two books have a very similar table of contents. So I picked a topic and compared how it was presented before buying it. Well, you know I decided to buy it after that test and so far I've been loving 95% of the pages.
The book style is what I look for: consistent and concise language, general to detail presentation style, right-first-wrong-after examples, (really) meaningful concepts highlighted, simple diagrams to aid visualizing the conceptual landscape.
I'm not writing any excerpt here as it would be premature, and I'll finish reading it before drawing the conclusion, but if I'll be happy as I am now when I finish it I'll give it 4+ stars without the shadow of a doubt.
It's big (700+ pages) but it's well structured and I think easy for the reader to find only the relevant parts. The size is also justified by plenty of pictures (diagrams and UI screenshots) and code presented in the second half. The examples are written in C#, I'm a Java developer. I had no issue understanding what they mean. Actually I preferred them as C# is more concise, so less to read to get what I need.
I hope this will help the community as there are so many projects turning in a "big-ball-of-mud"!
Questo libro è IMPLEMENTING Domain Driven Design.
Contrariamente a quanto riportato nella descrizione dei contenuti, questo libro non è assolutamente adatto a chi si avvicina per la prima volta al mondo DDD o è un principiante.
Per affrontare e comprendere gli argomenti trattati occorre conoscere approfonditamente i seguenti concetti (metto tra parentesi quelli che secondo me possono essere delle pubblicazioni adatte a colmare eventuali lacune)
- I principali design pattern, i principi SOLID ecc. (Head First Design Pattern)
- In cosa consiste il DDD, i principi di base, la nomenclatura, le architetture (Domain Driven Design di Eric Evans - l'inventore del DDD)
- Le principali architetture enterprise: CQRS, Event Sourcing ecc. (Microsoft .NET: Architecting Applications for the Enterprise - SECOND EDITION)
Se siete dei principianti o non conoscete uno o più degli argomenti sopra descritti, STATE LONTANI DA QUESTO LIBRO: vi causerà un'enorme confusione dovuta a spiegazioni poco comprensibili scritte con stile prolisso, con una montagna di concetti dati per scontati e in un inglese non proprio basico.
Se invece siete programmatori o architetti con esperienza nel settore, qui troverete delle preziosissime informazioni su COME gestire progetti complessi usando le tecniche e le architetture DDD, evitando gli errori più comuni e scegliendo la strada più adatta per ogni situazione.
La terminologia e i concetti descritti sono riportati con estremo rigore, dipanando ogni possibile dubbio sugli argomenti trattati.
Se quindi siete già ferrati sull'universo DDD, questo libro si dimostrerà preziosissimo e completerà al 100% la vostra conoscenza sull'argomento.
In caso contrario, prima di affrontarne la lettura vi consiglio di approfondire gli argomenti propedeutici, pena una estrema frustrazione.
If you really want to make your architecture robust, scalable and understandable you will need to work with the business, use ubiquitous languages with your areas of expertise and think in subdomains. How that is going to work alongside with how you finally implement things Vaughn explains in an non-academic way when possible.
For me as a non-native english reader it is quite beneficial that he points out things from different view points and uses an additional sentence to explain concepts here and there.
The first chapters are the most important for me as DDD really only works when you achieve a DDD mindset. That is costly for a company as there will be an overhead for IT to go the DDD route first but Vaughn also clearly explains the business value.
You will understand when it makes sense to buy new technology rather to build it yourself and when to clearly focus on what you need to build.
Last but not least, as the "implementing" part of the book's title promises, yes there are code examples and nicely explained. There is even a full implementation of his example on github.
Powerful book. A paradigm change if you allow it to be that can open up a new world of how you think about architecture, development and your business.