Health to the Web

  Domain Driven Design book - Eric Evans (2003) I love this book. So well written. Espouses good principals and practices which still apply today. Good examples to follow and learn from. (kindered spirit) Introduction domain - the subject area, area of interest e.g.  the domain of a restaurant system involves real people booking reservations at restaurants to create valuable software you need to understand the domain its for, models can help focus on what's important out of that large domain The domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge.  The domain model is the idea that the diagram is intended to convey; loosely representing reality to a particular purpose.  Developers have to steep themselves in the domain to build up knowledge of the business. Three basic uses for domain model: 1. the model dicta

A way of sharing state by passing state properties through components (which may not use the data themselves) to child components that need it. Kents article Prop drilling is appropriate in some circumstances and is explicit (which makes it easier to debug). Lifting state up to the closest common component and then passing it down to child components is a pattern that works for many cases and we use all the time.  But Prop drilling can come with problems if the shape/name of data properties change or child components change and no longer need the data We've seen this happens quite often as apps scale up in size: "hmmm what children components use those props? I dunno" or "why is this child component broken?" Kent says one way to avoid this is don't break out render into multiple components unnecessarily. Wait until you need to reuse.  Now this is interesting to me. Many times we break up components into separate components for reasons other than just reuse