DDD — Notes from the big blue book. Part 1

At Wiggle we have just begun a new developer initiative to collectively become better domain modellers. It consists of reading two chapters of the DDD book a week and then having a discussion about them on Friday afternoon.

My homework is now complete — I’ve read the first two chapters…. but I’ve also taken some notes about what I think are the key features. This should give me plenty to talk about on Friday.

A secondary benefit to my notes is that instead of reading the whole book again, I can just go over my notes at regular intervals to help commit the knowledge to long term memory (I’m a fan of brain science so I know a few tricks here).

Anyway, here are my notes for up to the end of chapter 2.Preface

·  A domain model’s ultimate benefit is that it allows successive versions of systems to be built on the existing ones. Eric Evans shows an example of teams not getting to release 2 because they weren’t domain driven.

·  Domain model is the most complicated aspect of some systems — not database etc

·  DDD must be used with an iterative process (eg. a flavour of agile). There must be close communication between developers and business people/domain experts

·  DDD is best applied by a whole team collaboratively, using a shared language

·  A domain model is NOT about being “as realistic as possible”. It should loosely represent reality to a particular purpose.Chapter 1

·  3 rules determine the choice of a model:

o  Model and heart of the design shape each other

o  Model is the backbone of language used by all team members

o  Model is distilled knowledge

·  The best developers should also model domains – not working on databases or frameworks

·  Effective modelling techniques taken from the PCB example:

o  Bind model and implementation

o  Cultivate language based on the model

o  Knowledge rich domain model

o  Distilling the model

o  Brainstorming and experimenting

·  Knowledge crunching — working towards a simple view that makes sense of the mass

o  Models are tried and rejected

o  Collaboration between devs and domain experts

·  Developers should understand the principles behind the software — not just what it should do

·  PCB example was eventually dropped — but those early sessions were the start of the knowledge crunching process that facilitated the later improvements the domain model

·  Business activities and rules are as important as the entities

·  The maximum booking rule was hidden as a guard clause, but later transformed into a policy. Express domain rules clearlyChapter 2

·  Ubiquitous language

o  Spoken by all developers and domain experts — **AND **expressed in code

o  Bottlenecks occur if only certain developers are “bilingual”

o  All people must use the same terms to describe the same things

o  Domain models can provide the ubiquitous language

o  Incorrect use of ubiquitous language will cause developers to clarify true meaning of domain terminology

·  Crucial to play around when formulating a ubiquitous language — just like sketching drawings

·  Reframe requirements in ubiquitous language as it evolves

·  Have only minimal documentation that feels sketchy and disposable to complement the domain model

·  Explanatory models of alternative views of the domain can be used as education tools — in no way related to code, though

See you next week suckers