seandenigris.com

My Behavior Driven Development research has turned me onto Domain Driven Development, as explained inDomain-Driven Design: Tackling Complexity in the Heart of Software.

• Brainstorming and experimenting are emphasized as the developer and domain experts model the the domain, channelling the massive amount of information into what is significant.  All work – even if thrown away – develops problem understanding and strengthens feedback loops
• The direct connection between developers and domain experts/users follows many iterations.
• The developers’ knowledge of the domain supports refactoring and abstraction, accelerating the development trajectory
• Analysts, domain experts, users and developers constantly keep the model conformant to business logic, user desires and software realities.
• Everyone involved develops and speaks using a common domain language
  • While advocating a common project language, the book describes all the developers & domain experts, with unique languages describing the system from their perspective, translating for each other. It conjures the Tower of Babel – with the juice of the knowledge slipping through the cracks in the translation. It seems so obvious that software is a language problem – how to translate from the world, to business rules, to developer jargon, to code, to assembly, to electrical signals without losing the meat of it.
  • The difference between vague technical discussions and precise domain model descriptions is striking
  • The common language lies at the intersection of developer language and domain expert language, covering only what’s relevent to the project.
• Patterns to keep code supple – a joy to work on and inviting change
  • Reveal the intention in the interface: name classes and operations based on effect and purpose, not implementation, using the common language. Force this by writing the interface you wish you had in tests.
  • Prefer Side-effect-free Functions – separate commands (have side-effects) into KISS methods that do not return domain data, and queries/calculations (no side-effects); use value objects when indicated.
  • Use Assertions (or Unit Tests) to promise pre/post-conditions & invariants (Programming by Contract)
  • The code wants to relax into its natural units.  Repeated refactoring and adaptation kneads it into conceptual contours – granular appropriate to the interest of the customers e.g. drivers don’t care about the fuel injector pressure, they want to know about acceleration.  Changes significantly breaking the domain layer are opportunities to deepen the model.
  • Annihilate all non-required coupling – to zero if possible – especially for the most complex computations
  • Prefer Closed Operations, which have the same type for all arguments (including the calling class if state is changed) and return value, to minimize dependency 

Ok, enough for today.  Very good focus on sound design.