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 operating cost?
C C C C C C C C C C C C C C LATE! REVISIT C C Three MMUs (simplified) One late arrival and double-back
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 of 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 My ¡Advice: ¡ • Auto-dispatching ignores nuances. Do ¡Nothing! • 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.)
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. “Sort of interesting, but what do we do with it?” • Mark “Deviations”: Each time “Daily” does not follow “Template”. Code-probe these • Mark “Exceptions”: Each time Actual doesn’t follow Daily. • Track late arrival, long wait, overtime … Exceptions Waste How much slack?
An Idea: Template Validator • How do they know if a “fix” improves the template? Statistically ¡ drive drive to C3 drive to C1 drive to C2 water wait water wait wait water Unsound! C Duration average drive time sequence * Route Customer Duration average watering time average wait time Duration
Scenario that breaks the model C1 window C3 window C2 window C2 window drive drive C2 drive to C1 drive to C2 drive C3 C wait water wait water water missed revisit window • 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 C1 window C3 window C2 window C2 window drive drive C2 drive to C1 drive to C2 drive C3 C wait water wait water water missed revisit window • Traversal Simulator models effect of cascading events by generating a single outcome at a time. Historical Probability Distribution Data drive time * Customer Route Probability Distribution sequence watering time windows * Interval
More Research
Statistical Modeling of a Route Log Normal Distribution mean sd drive time Normal Distribution * Route Customer mean sequence watering time sd windows * Interval • Also other factors, such as probability of a particular canceling on 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 of 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.
Recommend
More recommend
