Take a photo of a barcode or cover
mburnamfink 's review for:
Domain-Driven Design Quickly
by Abel Avram, Floyd Marinescu
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.
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.