📖Domain-driven design: tackling complexity in the heart of software

p.37-38 code as documentation is always unambiguous and it never gets out of sync. However it might be hard to understand or overwhelm with the details. Documents shouldn’t try to do what code does well

p.39 hand-drawn diagrams feel casual and temporary → Use hand-drawn diagrams to convey a feeling of casual and temporary

p.39 if document does not contribute to the project, not discussed, not used, keeping it up-to-date is a waste of resources

p.40 as comments, variable and function names can be out of sync from their content

p.49 use a single model for both analysis and software implementation

p.60 software development is all design. There is no separation of design and implementation. Having skilled “workers” do design and low-skilled workers do the implementation doesn’t make sense

p.60 separating design and implementation leaves design without feedback (or with delayed one)

p.70 (GT: inspector views are not end user interface)

p.70 separating domain into its own layer (independent of UI, storage, and specific application needs) allows it to evolve and get rich and clear

p.75 DDD requires only the domain level to exist

p.76-77 the smart UI “anti-pattern” is often a viable approach. not every project is ambitious

p.83 reduce associations to a minimum. unidirectional if possible. bidirectional association means two object can only be understood together

p.84 “qualified” relationships can help reduce multiplicity

p.89 entities (reference objects) vs value objects

p.91 “a thread of identity”

p.98 not every object needs an identity

p.98 value objects are “objects that describe things”

p.99 value objects should be whole (the whole value pattern by Ward Cunningham)

p.100 value objects should be immutable if possible

p.102 “bidirectional associations between two value objects just makes no sense”

p.110 modules are communication mechanism

p.111 modules are harder to change than classes, therefore they rarely do

p.112 wildcard imports better reflect the fact that two modules are cohesive

p.127 aggregates have a single root entity. The aggregate can only be referenced by that entity. Noone can hold a reference to other objects in aggregate out of context

p.128 entities inside the boundary have local identity

p.136 sometimes the object creation is too complicated or unrelated to the job the object is doing after constructed