Focusing the Core Domain Model A Domain-Driven Design Case Study, - - PowerPoint PPT Presentation

Focusing the Core Domain Model

A Domain-Driven Design Case Study, Eric Evans, Domain Language

• @ericevans0 #dddesign #yow13

Thirsty Fern FLLC

A Mostly True Story About Strategic Design and Focusing the Core Domain with Established Formalisms

Anonymized Case Study

• Client asked for discretion (competitive advantage).
• Fictionalized industry.
• Simplified.
• Retaining story sequence and factors that drove design.

The Business Problem

• House-plant watering service, growing rapidly.
• 48 Hydration Engineers (H.E.), each driving a Mobile

Moistening Unit (M.M.U.).

• Each visits about 11 customer locations per day.
• How to dispatch vehicles and people efficiently to allow

business to grow while slowing rise in overhead and

• perating cost?

Three MMUs (simplified)

One late arrival and double-back

C C C C C C C C C C C C C C

LATE! REVISIT

C C

Complicating Factors

• Some customers water Monday & Friday, some each

Tuesday, etc.

• Time windows (e.g. arrive between 10-10:45).
• Some customers give us a key – no window.
• Within the basic schedule, variability: Cancellations,

urgent extra waterings…

• Variability in driving time, waiting time, watering time.

Current Process

• Manually maintained route “Templates” (one for each van)
• “Daily” routes derived from templates daily and

extensively modified.

The Idea

• Algorithmically optimize dispatch
• Scrap templates entirely
• Automatic generation of daily routes
• Team reading up on operations research
• Learning prior art, established formalisms

Research

Generic Subdomain —> Why not off-the-shelf?

• Existing commercial software fully automates the process
• f assigning hydration engineers and determining their

sequence of visits.

• Spawn investigation of packages. Experiment with top

two:

• A is way too complicated. (Abort)
• B … might actually work. (Expensive)

CEO Comes to Call

• Glad to see motion on project
• Uneasy about auto-dispatch


• At least we are in the core domain!

Digging Deeper with Domain Experts

• Auto-dispatching ignores nuances.
• e.g. big advantages to continuity – same person

should visit a given customer most of the time.

• Black box makes it hard to use partially.
• Just doesn’t seem like it solve the problem as they see it.

(But nobody has a better idea.)

My ¡Advice: ¡
 Do ¡Nothing!

Don’t Develop When:

• Software is not strategic.
• (Need careful ROI estimate? Not strategic.)
• Off-the-shelf alternative is available.
• People do the job better than software.
• Stakeholders are dubious.

Touching the Core Domain?

• Keep digging with domain experts
• Research.
• Experiments and cheap prototypes.
• Patience under pressure to “deliver”.
• “Just build something” is bad strategy.
• Stay calm!

More Digging with Domain Experts

• Chaotic dispatching is hiding the root problems.
• Dispatching is chaotic because templates are unrealistic

and poorly structured.

• “We just need to fix the templates.”
• New view of problem —> New ideas for solutions

An Idea: Metrics for Templates

• Mine logs of “Actual” schedules.
• Mark “Deviations”:


Each time “Daily” does not follow “Template”.

• Mark “Exceptions”:


Each time Actual doesn’t follow Daily.

• Track late arrival, long wait, overtime …

Exceptions

How much slack?

Waste

Code-probe these

“Sort of interesting, but what do we do with it?”

An Idea: Template Validator

C

water drive to C2 water wait drive to C1 water wait drive to C3 drive wait

Statistically ¡ Unsound!

Route

average
 watering time sequence* Duration

Customer

average drive time Duration Duration average
 wait time

• How do they know if a “fix” improves the template?

Scenario that breaks the model

C

water drive to C2 water wait C1 window C2 window C2 window C3 window drive to C1 drive C3 water wait drive C2 drive missed window revisit

• Difficult to combine variability when elements of a sequence are not
• independent. Variability doesn’t wash.
• Sensitive to cascades of events. (e.g. What happens when we miss

a time-window?)

• Give up on this idea? (I’m big on giving up, actually.)

Patience is not the same as analysis paralysis.

<<Two more blind alleys omitted.>>

My Sister the Rocket Scientist

• Meteor and debris damage to space craft.
• Monte Carlo simulation of impacts, result of impacts, and

results of cascades of events.

Look at this diagram

• Isn’t it interesting?

Modeling a Route Traversal

• Traversal Simulator models effect of cascading events by

generating a single outcome at a time. C

water drive to C2 water wait C1 window C2 window C2 window C3 window drive to C1 drive C3 water wait drive C2 drive missed window revisit

Route

Interval watering time windows

*

sequence

*

Probability Distribution

Customer

drive time Probability Distribution

Historical Data

More Research

Statistical Modeling of a Route

Route

Interval Normal Distribution

mean sd

watering time windows * sequence *

Log Normal Distribution

mean sd

Customer

drive time

• Also other factors, such as probability of a particular canceling
• n a particular day.

Delivery of Version 1

• Small code-base.
• Hard-coded, procedural event cascades.


Polymorphic, pluggable distributions.

• Extraction of historical data from operational logs.
• Storage of routes in legacy routing system.
• Built Monte Carlo Simulator framework.
• (Easy. And off-the-shelf “didn’t seem to offer much”.


Hmm…)

Results

• Dispatching is less chaotic.
• —> Dispatchers can see what’s happening.
• —> Leads to many subtle improvements.
• Algorithmic optimization would actually be naive.
• Still experimenting with metrics.
• Slower increase in MMUs? We’ll see.

Modeling

• Established formalisms can slim down 


core domain model and give it clearer expression.

• Research.
• Domain modeling is modeling, not OO modeling.

Version 1 Problems

• Slow performance. Discouraged iterative use. People start it

and come back.

• Performance variable by 10x. Developers don’t know why.
• Legacy data structures contributing to slowness.
• Cache doesn’t work the way they think it does.
• Code getting messy mostly because of legacy integration

creeping in everywhere, and using legacy concepts that didn’t fit.

• Messy + slow—> Not composing into new capabilities.

Bounded Contexts

• An explicitly defined part of a software system in which a

model’s definitions and assertions strictly apply.

• Typical boundaries: a subsystem, a service boundary, a

set of packages and a set of tables, a different technology platform…

• Version 1 had queries to operations database to get

customers, windows, templates, plus watering times, etc.

• Version 1 boundary is not good enough!

Separately Deployed Service — Set Rules

• Initialize service with historical watering times/drive times.

Compute distributions. No other access to legacy. Replicate/recreate at will.

• Hold model data in-memory.
• Feed Monte Carlo simulation requests via a queue.
• Completely separate build/deploy/data.
• Makes context boundary clear and seem important.

Version 2

• Fast simulations, and easily run in parallel
• Users began fiddling interactively with routes to see effect
• f changes.
• Code cleaned up and staying clean.
• Prototype for Version 3: Simulation of full sets of routes.

User drags customer to different route and gets immediate feedback on performance of set.

Strategic Design Exploration

• Patience, persistence, experimentation. (Avoid analysis

paralysis).

• Queasy domain experts are not a good sign (about the idea).
• Interest from upper management is a good sign (about the

area of focus).

• Hit the sweet spot with small things (might not grow).
• Bound the context.
• Good internal designs often look like products.