Shop now Shop now</arg> Shop now Shop now Shop now Learn More Shop now Learn more Shop Fire Shop Kindle Listen with Amazon Music Unlimited Shop now

Customer Reviews

4.2 out of 5 stars
30
4.2 out of 5 stars
Your rating(Clear)Rate this item


There was a problem filtering reviews right now. Please try again later.

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| 16 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 4 August 2006
I dont think I could possibly disagree with the previous review any more. This is, IMO, the best software design book I have ever read. It is certainably the one that has had the greatest effect on my software design.

The book is written superbly. Eric breaks down various parts of the domain into categories and describes what they are, their benefits and relation to the whole picture in a way that just makes sense. I have used the techniques and they simplify the design and make it possible to go straight to a domain expert and take software instead of having to talk 2 seperate languages.

I dont find the book hard to read at all, and im not overly educated. If you want an example of hard to read, GangOfFour; a fantastic book but not easy reading. This book is written well, full of experience and well worth a read.

100% recommended.
0Comment| 25 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 28 April 2007
What can i say...this is a fantastic book. It's about getting back to basics and understanding what your trying to build and sharing a common language. The patterns described in the book are very helpful and i have already started to implement some of the recommendations.

Buy this book..it's worth it. If your worried about it being a length read, you can go to the domain driven design site and they have a concise version of the patterns to read. But I highly recommend that you get the book and read it from cover to cover.
0Comment| 10 people found this helpful. Was this review helpful to you?YesNoReport 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| 13 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 26 September 2006
If your doing, or thinking of doing DDD, then you should certainly read this book.

The writing style is excellent, the ideas are interesting, the persentation is superb and (most importantly) good examples are provided along the way.
0Comment| 13 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 9 June 2014
While it can be tough going in places it is well worth sticking with. Both developers and managers alike should take the time to get the grips with the concepts of DDD. A common domain language is one of the most essential concepts for a software house to have it's core. Couldn't recommend this book enough.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on 31 March 2016
One of the best books on software development I have ever read along with the Vaughn Vernon one (Implementing Domain Driven Design). I think if I had to recommend just one book for someone to read in order to become better at software development, it would be one of these two.
0Comment|Was this review helpful to you?YesNoReport abuse
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?YesNoReport 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| 5 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 19 June 2014
As I read this book my heart sang. The writing is clear, subtle ideas are articulated well, and the entire book is packed with gems of outstanding quality and brilliance.

This book contains the best information about software design that I have ever encountered and also provides lots of guidance on how to make best use of the wealth of knowledge it contains.
0Comment|Was this review helpful to you?YesNoReport abuse

Sponsored Links

  (What is this?)