Luboš's Reviews > Domain-Driven Design: Tackling Complexity in the Heart of Software
Domain-Driven Design: Tackling Complexity in the Heart of Software
by
by
![16037775](https://images.gr-assets.com/users/1357214115p2/16037775.jpg)
It is a quite famous book but I did not enjoy it. I finished the book just because we had been reading it together with my colleagues. There are several interesting poinst but otherwise it is too long. Indeed, summary at InfoQ is available.
Sign into Goodreads to see if any of your friends have read
Domain-Driven Design.
Sign In »
Quotes Luboš Liked
“Most talented developers do not have much interest in learning about the specific domain in which they are working, much less making a major commitment to expand their domain-modeling skills. Technical people enjoy quantifiable problems that exercise their technical skills.”
― Domain-Driven Design: Tackling Complexity in the Heart of Software
― Domain-Driven Design: Tackling Complexity in the Heart of Software
“Simple, informal UML diagrams can anchor a discussion.”
― Domain-Driven Design: Tackling Complexity in the Heart of Software
― Domain-Driven Design: Tackling Complexity in the Heart of Software
“Any technical person contributing to the model must spend some time touching the code, whatever primary role he or she plays
on the project. Anyone responsible for changing code must learn to express a model through the code. Every developer must be involved in some level of discussion about the model and have contact with domain experts. Those who contribute in different ways must consciously engage those who touch the code in a dynamic exchange of model ideas through the UBIQUITOUS LANGUAGE”
― Domain-Driven Design: Tackling Complexity in the Heart of Software
on the project. Anyone responsible for changing code must learn to express a model through the code. Every developer must be involved in some level of discussion about the model and have contact with domain experts. Those who contribute in different ways must consciously engage those who touch the code in a dynamic exchange of model ideas through the UBIQUITOUS LANGUAGE”
― Domain-Driven Design: Tackling Complexity in the Heart of Software
“But, while bidirectional associations between ENTITIES may be hard to maintain, bidirectional associations between two VALUE OBJECTS just make no sense. Without identity, it is meaningless to say that an object points back to the same VALUE OBJECT that points to it. The most you could say is that it points to an object that is equal to the one pointing to it, but you would have to enforce that invariant somewhere.”
― Domain-Driven Design: Tackling Complexity in the Heart of Software
― Domain-Driven Design: Tackling Complexity in the Heart of Software
“When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as a standalone interface declared as a SERVICE. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LAN- GUAGE. Make the SERVICE stateless.”
― Domain-Driven Design: Tackling Complexity in the Heart of Software
― Domain-Driven Design: Tackling Complexity in the Heart of Software
“Listen to the language the domain experts use. Are there terms that succinctly state something complicated? Are they correcting your word choice (perhaps diplomatically)? Do the puzzled looks on their faces go away when you use a particular phrase? These are hints of a concept that might benefit the model.”
― Domain-Driven Design: Tackling Complexity in the Heart of Software
― Domain-Driven Design: Tackling Complexity in the Heart of Software
Reading Progress
March 18, 2018
–
Started Reading
March 18, 2018
– Shelved
June 12, 2018
– Shelved as:
software-development
June 12, 2018
–
Finished Reading