Domain-Driven Design Quickly

by Floyd Marinescu, Abel Avram

Domain Driven Design is a vision and approach for dealing with highly complex domains that is based on making the domain itself the main focus of the project, and maintaining a software model that reflects a deep understanding of the domain. This book is a short, quickly-readable summary and introduction to the fundamentals of DDD; it does not introduce any new concepts; it attempts to concisely summarize the essence of what DDD is, drawing mostly Eric Evans' original book, as well other sources since published such as Jimmy Nilsson's Applying Domain Driven Design, and various DDD discussion forums. The main topics covered in the book include: Building Domain Knowledge, The Ubiquitous Language, Model Driven Design, Refactoring Toward Deeper Insight, and Preserving Model Integrity. Also included is an interview with Eric Evans on Domain Driven Design today.

Genres: Programming, Technology, Software, Computer Science, Nonfiction, Technical, Engineering

104 pages, Paperback

First published January 1, 2006

Reviews

[Johnny · Rating 4 out of 5]

Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans is hard to read and full of repetition. It has great points like the ubiquitous language, refactoring toward a deeper insight or bounded context but to get to those points you have to work. It’s like mining and most of the pages you have to read don’t turn out to be useful.

This book, Domain-Driven Design Quickly, is an easy to read summary that explains the main points of Domain-Driven Design. Without the repetition and only small but meaningful examples you can get up to speed in no time and start exploring the topic on your own with real code. If you made your own experiences and like to go a bit deeper in certain points you still can go for the book of Eric Evans.

[Chris Daviduik · Rating 3 out of 5]

A pretty good summary of DDD, but often feels a bit fragmented and disjointed. Like you're trying to read someone's notes for a day long lecture you missed. There are also quite a few spelling errors which surprised me and made some of the descriptions confusing at times.

In the absence of having read anything better this seems like an alright intro to and reference for DDD, but I'll continue looking elsewhere. In the end though I should probably just buckle up and read the famous Eric Evans book...

[Tomasz · Rating 4 out of 5]

Good and concise introduction to Domain Driven Design. Maybe some areas are not covered very deeply but it's still good read.

[Jim Hult · Rating 1 out of 5]

Poorly written. Several times, wording is off and makes one wonder if this book ever has been reviewed.

The author dances with word so much that sometimes you read several sections and realise you have not gotten anywhere.

For a book that is supposed to summarize a topic, there is an awful amount of bullshit words that do not convey a message. In this book, many times, you can summarize 2 pages into 2 sentences.

[Gediminas · Rating 3 out of 5]

A decent summary of DDD, but no more
Read it if you want a quick refresher or introduction to the main concepts of DDD and the reasoning behind them.

However, if you are seeking a deeper understanding of DDD, you should safely skip this one and pick "the blue book" or "the red book" instead.

[Michael Burnam-Fink · Rating 3 out of 5]

Writing software is easy.

Writing software that doesn't suck is actually hard.


4 of 5 developers enjoy code review

And maybe I'm cranky because I've spent 13 hours in meetings these past few weeks with the only take-away being that people still do not understand basic elements of our technology stack, but writing software in a modern, collaborative, agile, corporate environment is really hard. And it's rarely the tech these days, it's the people.

I was introduced to Domain-Driven Design in Architecture Patterns with Python, and thought the concept was interesting enough to be worth some research. This is the short (100 page) version of Evans (400+ page) big book.

Brevity is a blessing and a curse. Certainly, this book is very approachable, but the basic idea of isolating business logic in domains such that a mental model of a business process is easily mapped to a software object, and then using abstract repositories so that you're not tied to specific implementations of a technology, is pretty obvious. The jargon of aggregates and immutables could use some better explaining.

And the actual work of getting fundamentally confused people from many units to work together is left as an exercise for the reader.

[Geert · Rating 4 out of 5]

Alright introduction to domain-driven design for those unfamiliar with it. Condenses key concepts in a mostly efficient manner. Problems: too abstract for a layman, too longwinded for someone with basic OOP knowledge. Fantastic for a free resource, but would not give it the same rating had I paid.. say $20 for it.

[Alberto Alcaide · Rating 4 out of 5]

Very good summary of what is DDD, however do not remeber well enought all the book.

[Philip · Rating 4 out of 5]

It's a very "right to the point" book about DDD. I really enjoyed the way it presents the core concepts, in a very resumed way.

[Stephen Kawaguchi · Rating 4 out of 5]

This was a good overview of DDD and offers some additional insights. Read this is you want a refresher on DDD or want a crash course.

[Reza · Rating 2 out of 5]

خیلی خلاصه؛ برای آشنایی خوبه ولی برای کاربرد دانش ناچیزی را ارائه میدهد.

[Di Wen · Rating 4 out of 5]

Great book as a quick intro to DDD, just like a ... Context Map.

[Lingfan Liang · Rating 3 out of 5]

Summary

I cannot finish the original domain driven design doc by Eric Evans as it's too dry and sometimes lack of focus so I pivoted to this book to learn about DDD. DDD fits well into currently popular microservices trend. However, this book lacks sufficient examples and detailed tips on how to apply DDD to practical situations. The most important learnings of the book is: use ubiquitous within EPD, model domain in a well contained bounded context and map it to your team structure.

Raw Reading Notes

1. Use ubiquitous language to communicate between engineering, product , and stakeholder
2. write text message + diagram to illustrate models
3. Keep design and code in sync by referring to design while coding, and updating doc if necessary
4. Model driven design
1. Entities are objects with an identity, which remains the same throughout the states of the software. For these objects the values don’t matter, only the identifier. Only create Entities for the most important parts of the domain.
2. Value Objects are objects where we are only interested in it’s attributes. They don’t have an identity. It is recommended to make Value Objects immutable. Keep Value objects thin and simple.
3. Services provide functionality for the domain. Functionality that cannot be incorporated in Entities or Value Objects because it functions across several objects. Services can appear in each of the layers.
4. Modules are used as a method to organise related concepts and tasks in order to reduce complexity. Modules should be made up of elements which functionally or logically belong together.
5. An Aggregate is a group of associated objects which are considered as one unit with regard to data changes. Each aggregate has a root Entity and that is the only object accessible from the outside. Other object in the aggregate can only be changed by performing actions on the root, never directly on the other objects.
6. Factories can encapsulate the process of complex object creation. They are especially useful to create Aggregates.
7. Repositories encapsulate the logic for storing and retrieving objects. They hide the logic of for example a database, files or communication with an external service and may use for example caching.
5. Bounded Context: A model should be small enough to be assigned to one team. There is no formula to divide one large model into smaller ones.

6. Context Map: An enterprise application has multiple models, and each model has its own Bounded Context. It is advisable to use the context as the basis for team organization. A Context Map is a document which outlines the different Bounded Contexts and the relationships between them. (e.g. a high level architecture)

[Jeff · Rating 3 out of 5]

This is a rough but quick and distilled introduction to domain-driven design (DDD). The existence of some grammatical errors indicates that this book was probably hastily written without much editorial contributions. But that doesn’t matter much; the grammatical errors are not fatal to comprehension, and the book gives just enough to start with. The book concludes with an interview with Eric Evans, the originator of the concept of DDD. The natural next step after this book is to go ahead and tackle Evans’ full treatise on the subject, Domain-Driven Design: Tackling Complexity in the Heart of Software .

[Jose Gabrielle Rivera · Rating 4 out of 5]

Great book to quickly get your feet wet with domain-driven design. As software engineers, our job is to capture and translate business requirements into working software. That is a task easier said than done, especially when working in a complex business domain. Fortunately, DDD exists to share its ideas and principles on how we could achieve that. This book gave me an overview on what DDD is and most importantly, why we should strive to do it. Sadly, the book has some minor issues such as typographical errors. But nevertheless, it's still a decent read. Overall, I feel more confident now to read about Evan's blue book and Vernon's red book on DDD.

[Anton Antonov · Rating 5 out of 5]

Are you wondering whether to commit to Eric Evans' nearly 600-page book about Domain-Driven Design (DDD), a subject that's been praised by so many?

I was, too. I wondered why I'm recommending colleagues read Eric Evans's DDD book when I remember how long it took me to read it.

You don't need 600 pages to quickly understand the lingo of Factory, Anti-Corruption Layer, Aggregate, Bound Context, Repository, Entity, etc.

This book takes a really straightforward approach to explaining and reviewing DDD at a quick pace. At the light 104 pages, it's just worth reading if you're having second thoughts about DDD. 😀

[Philip · Rating 4 out of 5]

Good overview of the Domain Driven Design paradigm.

This book is available as a free ebook online, and it shows. The quality of the editing is pretty bad, with spelling mistakes, missing or extraneous words, and in one case missing the whole second half of a sentence.

It also fails to explain why the ideas are good; it explains some of the tradeoffs, but often it also just explains a concept in isolation.

But you can get all of those details from other sources, and I haven't found a faster way to grasp the whole paradigm than by reading this book.

[Arun Ravindran · Rating 5 out of 5]

Good summary of a great book. Have heard lots about the book Domain Driven Design but have never got around to completing it due to it size.

The concept of DDD is quite useful when you are designing a large and complex software solution like an ecommerce website. That does not mean it cannot be applied to smaller projects. It gives you concepts like entities and value objects which you might eventually discover or relate to.

I am happy that this book gave me an idea of what DDD is about. I might read Eric's book some day!

[Martin Ridgway · Rating 1 out of 5]

Really poor.
I picked this as an introduction to this thing that got a lot of praise in various blogs: domain-driven design.
But the book here just doesn't make sense. I can only assume that there are loads of unstated assumptions that Marinescu hasn't even considered necessary.
And the typos ...!
I spend a few pounds on a second-hand copy and I feel ripped off, I pity anyone who spend $30 for under 100 pages.

[Samuel Taggart · Rating 4 out of 5]

A good overview of domain driven design. Just the highpoints, but that is to be expected considering it is a 100 page book meant as a condensed version of a 500 page book.

If you are new to DDD as I was, then it's a good starting point.

It's a quick easy read. Probably a couple days as some of the topics take a little time to digest especially if they are new.

The prose isn't necessarily the most entertaining, but it's not too bad. It reads better than a text book.

[Thiago Colares · Rating 4 out of 5]

I had partially read the blue book, by Eric Evans, years ago and have been using most of DDD concepts since then. DDD Quickly fulfills its purpose giving an overview of what DDD is and summarizing its building blocks using good examples. But if would like to one step further to implement those concepts, go check Eric's and Vernon's books along with example projects.

[Mohit Khare · Rating 5 out of 5]

Must for engineers, especially backend folks.

I could relate with many of topics, where I don't think about the big picture of the domain ( Like how they should be modelled that they can be easily extended, used by others, integrate with new features, etc.)

This is a good revision of core modelling concepts.

[Lincoln Karuhanga · Rating 4 out of 5]

Good overview. I came into this having watched a few conference talks and discussed with a few colleagues and trying to get my mind ready for the original book. It does a great job of doing that and gets you asking the right questions that are properly addressed by the main book, which I’m now treating as a reference.

[Hilmar · Rating 3 out of 5]

A decent summary on DDD as of 2006. Not sure if I would recommend it for modern readers, except as perhaps a glance into what things looked like in the past.

It does a good job of motivating the concepts of DDD, but it puts their definitions far from the top of the segment introducing them. I would prefer it if it defined it in the beginning and then motivated it.

[Mark Fermill · Rating 4 out of 5]

I love the example graphs, especially the one about air traffic monitoring system. Those graphs helped me easily visualize the point of a certain topic. The only issue I had with this book was that it was littered with terminologies and jargons that I sometimes don't understand.

[Lucille Nguyen · Rating 3 out of 5]

It's a series of lecture notes on Domain-Driven Design. Not much else to note, not particularly well written but it's concise enough that one can get the general thrust of the ideas. It's a software book, what do you expect?

[Matija · Rating 5 out of 5]

Nice intro to DDD. Good pointers for further education. Enough meat to make it worthwhile.

[Farhodjon · Rating 4 out of 5]

Gives a quick introduction to DDD, but this is not enough to deeply understand DDD.

[Shenyu · Rating 4 out of 5]

Nice little ebook for understanding the basic concept and motivation of DDD.

[Kirill · Rating 5 out of 5]

Good introduction into Domain-Driven Design. I have to read the original book by Eric Evans.