Learn more Download now Shop now Browse your favorite restaurants Shop now Shop now Shop now Shop now Shop now Learn More Shop now Learn more Shop Fire Shop Kindle Amazon Music Unlimited for Family Shop now Shop now Learn more

on 9 January 2009
To me this book has been a huge disappointment. Someone told me "Pete, there's a name for what you do!" and pointed me to this book.

Now personally I prefer technical books, as I read the Ubiquitous Language part at the start I thought to myself "Not technical, but fair enough some people will get value from being taught how to ask questions" and I stuck with it.

The first thing I must say that I cannot stand and which happens a lot in this book is over emphasis. When you want to emphasise something it needs to stand out. This book not only emphasises whole paragraphs but does it far too often too. Being an Internet user for some time now when I read upper case letters the imagined vocalisation actually SHOUTS at me, when I read bold my brain vocalises it as a loud and punctuated word, so when I read a whole paragraph in bold I, READ, EACH, WORD, LIKE, THIS; it makes it difficult to read.

Another thing I don't like when reading something is reading it for the Nth time. I don't mind a bit of reiteration in the way of reading something and then at the end telling me it is another example of "X" but only if the example is so different that it probably didn't occur to me. When I am on page 400+ I really don't want to be reading more examples of what I was reading in the first chapter. It really switches my brain off when so far into the book I am reading yet another example of "The Ubiquitous Language" that was covered at the start of the book. To be honest I am finding it very difficult to motivate myself to read the remainder of the book.

So, what have I learned from the book? I would say I have learned 1 valuable thing. Many times in the past I have modeled a parent/child association such as PurchaseOrder, and then modeled a kin-like parent/child such as Invoice/InvoiceLine, where the invoice is always for a single order and each invoice line is for a specific order line. In these circumstances I would have both Invoice.Order and InvoiceLine.OrderLine, everytime I did this I would cringe, it just felt "wrong" or "messy". Enforcing the idea that I should have no direct associations to the aggregated parts of the Order means that now I merely have Invoice.Order, it's easy to see which order line the invoice line is for because they are ordered the same and both the order and invoice are immutible. Now, I don't agree with the idea of never referencing an aggregated part, but at least now I consider the option. It certainly cleaned up a 3 kin-like aggregate part of the model I am currently working on.

For someone who doesn't know how to talk the "language of the current domain" with a customer I can see that this book could be useful, and also for people who need some pointers on how to segment their apps a bit.

When I read about people mentioning the "map of the world" example being such an eye opener (or whatever other way they express their positive experience) it honestly amazes me. The idea that a "Customer" to company A is completely different from how company B sees one as a break though just makes me shake my head in disbelief. In some businesses a customer is a company, in others a person, in others it could be either, and in one domain I worked a customer could have been either

A: A company
B: A department
C: An individual
D: A non physical entity such as a business process

All of which could also be a "Supplier". This is because they saw their Customers and Suppliers as things that consume and things that produce.

On the whole I personally found the book to be "a whole lot of nothing much at all", some of the personal stories were interesting but I also mainly found it repetitive and boring; a very difficult read. Unless the last 100 pages or so have something knock-out in them I expect I will remain very disappointed with it, if I ever manage to read the end that is.

Some people seem to be quite religious about this book, referring to it as "The book" and I feel by posting this negative review I might be opening myself up to attacks from DDD-extremists :-)

The fact is that I use parts of the DDD approach (now I at least know by what name to refer to it), it's just the book...
11 Comment| 14 people found this helpful. Was this review helpful to you? Report abuse
on 18 February 2015
I have read many technical books, but I've never read anything as badly written as this. The book is full off uncertainties, sentences that can be taken out completely as they add absolutely no value. It's written in an unnecessary complex English which actually hides all the goodness that the book probably has to offer. Some paragraphs can be rewritten in few words, so this makes me think that the author was chasing some magical page number. I'm hugely disappointed and I hope somebody completely re-writes it.

For example, "Providing access to other objects muddies important distinctions". Ok, what important distinctions? Who uses word muddies?

The author talks about importance of using the same language as the stakeholders, and then goes off and picks synonyms, making this a dreadful read for the rest of us.
11 Comment| 6 people found this helpful. Was this review helpful to you? Report abuse
on 27 April 2009
Anyone who has worked with me knows that, before, when i was doing coding work, I could only work in complete silence cos i had to concentrate so hard. This meant i couldn't get any work done in the office during normal hours cos there were always interuptions and disturbances.

Every disturbance meant that i had to spend 15-20 mins just getting back to the mental state from which i could continue working again. Hence, i had to work weekends and do all-nighters. Hence - I spent soooo much time working and not having fun.

This is all 'cos i was having to deal with really complex code. I was always spending time and energy trying to *reduce* the complexity. But, this book has really told me to STOP *trying to reduce the complexity*. It aint gonna happen - it IS complex.

Instead - It tells me how to *handle* the complexity. By handling the complexity, it means that i can work better. Quickly getting back to 'where i was' mentally after an interuption. It allows me to work, during normal hours, productively.

So, now I am FREEEEEEEEEEE - woo hoo!

Paraphrased Quote from Page 265: from the book: Domain-driven Design, By Eric Evans

"In every programming environment, a few basics are so pervasive that they are always in mind...

For example,..[the concept of "numbers"] don't add to the intellectual load. Beyond that, every additional concept that has to be held in mind in order to understand [the software you are building] contributes to the mental overload...

..Low coupling (one tenet for handling complexity) is fundamental to [software] design. When you can, go all the way. Eliminate all other concepts from the picture. Then the class [a bit of code] will be completely self-contained and can be studied and understood alone. Every such self-contained class significantly eases the burden of understanding the ..[the software you are building]"

Basically - if you are mildly geeky i recomend this book!
Sermon over.
0Comment| 3 people found this helpful. Was this review helpful to you? Report abuse
on 25 May 2008
I read this book 3 years ago, and DDD has been my preferred design concept ever since.

However, I have to agree that this book uses a highly sophisticated language, which is very difficult to read for a non-native English person.

Also the book is way to long. I wrote an internal summery, which is about 10 A4 pages, and it contains all key concepts about DDD. This book should have been no more that 200 pages.

The thing is that DDD is actually a very easy concept, but this book makes it overly complicated, and the concepts drowns in unnecessary details.

Also the book lacks examples. There is almost no code. A sample solution, would make a big difference.

Today there is a few online resumes on the Internet, which is much better that the book.

5 starts for the concept DDD. 3 stars for this book.
22 Comments| 5 people found this helpful. Was this review helpful to you? Report abuse
on 22 October 2013
I am very mixed up about this book... most other devs I know appear to have read the shortened version (I hear this means the bits in bold) and understand it perfectly. I find it hard to believe, as there's so much more information in the non-bold bits that to read just the bold bits would be totally misleading.
However, I find this book so hard to read at the same time. It's a great topic and all developers need to understand this modelling technique properly as this is the basis of the new age of software development. But it lacks analogies and a range of examples to better explain what he means, which means that he uses a very terse descriptive that is hard to process. I think several people should've written it and put in their experiences of the approaches they used and their experiences.
The first quarter of the book is particularly annoying as it talks about what you are about to learn all the time. I think he also means for it to be used as a reference, but it's far too verbose and waffly and not split up enough conceptually to be useful for that.
0Comment| 20 people found this helpful. Was this review helpful to you? Report abuse
on 7 March 2010
This is a book with some great content, sadly "the delivery" makes it an extremely hard and boring read. As much as I would urge anyone involved in developing software to become familiar with DDD concepts, it has to be said that that book, which I expected to be "the bible" on the subject, fails to impress. It is full of repetition and to make things worse the language is not the easiest either.
11 Comment| 14 people found this helpful. Was this review helpful to you? Report abuse
on 1 June 2017
This book is not something light to dip into and offers a very deep examination of modelling. I got a huge amount out of it; It went through a number of the practical problems that I've encountered before and helped me to properly understand the patterns that I used to solve them. Evans introduces concepts that are extremely useful when considering how to decompose a monolithic application into micro-services. I believe that this book will reward the effort that it takes to study it.
0Comment|Was this review helpful to you? Report abuse
on 27 September 2017
I hate this kind of books. They are expensive, theorical, but after reading it, your real life, your skills, your job and your results are the same. This book don't make any difference. It just gives you some concepts (interesting concepts by the way), but if you expect to be a better developer that can develop better code or system, then good luck. Is faster/easier/realistic to navigate through different projects in github and study what they do.
0Comment|Was this review helpful to you? Report abuse
on 29 July 2017
This is one of the most important books about software I've ever read. The low-level design advice is nice, though might benefit from a functional programming update. But the parts about strategic design are crucial to building systems at a scale larger than a single team. This book gives us a practical way to deal with the inescapable reality of Conway's Law.
0Comment| One person found this helpful. Was this review helpful to you? Report abuse
on 31 March 2006
I wanted to read on the subject "Domain-Driven Design" and I saw references to this book in Martin Fowlers "Patterns on Enterprise Application Architecture"

The first thing that you will notice as a non-native English person is that you have the impression that the script has been correct by several PhD's in English literature. A lot of words have been replaced by far more complex synonyms.

I have lost a lot of time re-reading a lot of sentences and looking up English words just to understand the construction of the sentences, and by the way I am referring to non-technical words. My English is far from perfect but during my career I have done lots or reading of technical books and this is the first time I had problems with the used English. Because of this I had to give up after reading 1/3 of the book.

I don't blame Eric or the reviewers of the script for the fact that they are so talented in their native language.

"I've come to my current specialty by a winding path; several threads converged to give me a viewpoint that couldn't have been planned. Of course, I can fit it all neatly together now, through hindsight."

Seriously, I have to read this several times after looking up words like converged and hindsight. If you write a book that is intended to be for an international audience that didn't study in the UK or the USA don't assume that they have an expert knowledge of the English langauge and have the book reviewed by someone that didn't study in the UK or USA.

Because I didn't finish the book however I cannot say whether this book is worth reading or not. Ongoing from other reviews and blog entries I have to conclude that if you are a native-English person you should definitely give this book a try!
0Comment| 15 people found this helpful. Was this review helpful to you? Report abuse

Sponsored Links

  (What is this?)