Domain-Driven Design by Eric Evans
- p 4: “The heart of software is its ability to solve domain-related problems for its users”
- p 61: Model-Driven-Design = the model supports an effective implementation and abstracts key domain knowledge
- p 81: three patterns for model elements (object): ENTITY, VALUE OBJECT, SERVICES
- p 98: Software Design is a constant battle with complexity
- p 98: An object the represents a description aspect of the domain with no conceptional identity is called VALUE OBJECT
- p 99: When you are only about the attributes of an element of the model, classify it as VALUE OBJECT. Treat the OBJECT as immutable. Don’t give it any identity and avoid the design complexity necessary to maintain ENTITIES
- p 110: If your model is telling you a story, the MODULES are the chapters
- p 136: When creation of an object becomes complicated or reveals too much of the internal structure, FACTORIES provide encapsulation
- p 243: When software with complex behavior lacks a good design, it become hard to refactor or combine elements
- p 243: Duplication starts to appear as soon as a developer isn’t confident of predicting the full implication of a computation