The language Clojure takes the distinction between entity + value very seriously. If you're interested, Rich Hickey has a talk called the Value of Values about this.
Customer is my entity, but the property CustomerName in that Customer entity is value object. Because internally CustomerName is made up of firstName and lastName.
You did not like the second half of the book which is the most important part of the book, strategic design. Even Eric Evans said that if could write the book again, he would move to second half to the beginning of the book, maybe even discard tactical patterns.
I'll take a second look. There is some good parts from the second half that I really enjoyed such as conceptual contouring, but there were other sections I personally did not find it very useful. This is a personal opinion and nothing against the writer.
I am going through this book right now and man there is way too much gibberish. It's too bloated. Author could probably have shrunken down the content to 150-200 pages but there is way too much going on in it. Still a decent book though, gives you a good idea about how to design and develop a software.
![[Gegagedigedagedago] NEW Help Gegagedigedagedago Nugget escape from Nikocado Avocado Challenge](http://i.ytimg.com/vi/hJWnwRC2Fz8/mqdefault.jpg)
What are your Entity Objects in your application?
The language Clojure takes the distinction between entity + value very seriously. If you're interested, Rich Hickey has a talk called the Value of Values about this.
Customer is my entity, but the property CustomerName in that Customer entity is value object. Because internally CustomerName is made up of firstName and lastName.
we have Meeting (its a scheduling tool). A Meeting starts as peding and can be approved or denied, and then it is elapsed.
You did not like the second half of the book which is the most important part of the book, strategic design. Even Eric Evans said that if could write the book again, he would move to second half to the beginning of the book, maybe even discard tactical patterns.
I'll take a second look. There is some good parts from the second half that I really enjoyed such as conceptual contouring, but there were other sections I personally did not find it very useful. This is a personal opinion and nothing against the writer.
Exactly. DDD is about strategy. Tactic is flexible.
VO represents the immutable state of entity. VO is basically functional paradigm applied to OOP. Services are procedural.
Good summary! thank you!
Well said.
Great content! Well structured video, and always a plus to have the reader's likes and dislikes.
Definitely gonna give it a chance.
Thanks!
Thanks Lea! Super glad you enjoyed and I hope you like the book!
You speak so well!
Thanks doda!
very well explained, thank you very much
Glad it was helpful Julian!
I am going through this book right now and man there is way too much gibberish. It's too bloated. Author could probably have shrunken down the content to 150-200 pages but there is way too much going on in it. Still a decent book though, gives you a good idea about how to design and develop a software.
Nice 👌
Thank you! Cheers!
Keen on reading this, do you think this book is relevant anyone?
Hi Upake, I definitely think it is still relevant!