20191010 - LASCOT2019 - Domain Prototyping or Design is how it Works, Tobias Goeschel @w3ltraumpirat

by Thierry de Pauw on


Domain Prototyping or Design is how it Works, Tobias Goeschel @w3ltraumpirat

Design is not just what it looks like and feels like. Design is how it works." -- Steve Jobs @w3ltraumpirat

This is also applicable to systems designs.

Design is how "it" works. it = Business

What is true for product design is true for systme design.
We have to understand the whole.
Feedback is absolutely key for that.
The quicker and the more often we can get feedback is important.
And for this, the lead time for getting feedback is key.

Good Design?

can we find generic solutions to save money?
we must evaluate {buzzword}
we have to integrate with our legacy system!
first user story: "login"
performance issues, GDPR, all kind of things need to happen

technology choice imposed
assumed usage is unrealistic
developers favour the tools they already known
and off course the system has to be distributed

first law of distributed: don't do it. @w3ltraumpirat

time until first release: weeks
time until first stakeholder feedback: months

we tend to make the most consequential decisitions at a time when we have by far the lease knowledge about our system @w3ltraumpirat
revirsing these deicsions is expensive
sunk cost fallacy becomes a big problem

Best practices:

design by template
design follows framework: everything follows Spring, Ruby on Rails, ...
there is a single way to design systems => the single system syndrome: the first time you build a system, you fixed all the problems you
encountered and since then every system have to follow these patterns @w3ltraumpirat
that's the way we do things here
the planning fallacy

Best practices are not best, they are good => see Cynefin

best practices apply to simple problems
if anything software develpment addresses complicated problems
usually they are technological
people and learn problems are complex

we must explore the problem to know if a solution will fit
to do that we need to run experiments => hard to sell, how are you going to budget that @w3ltraumpirat

How do we get there?

look at UX Design:
- uses an iterative approach
- it uses personas
- we start very simple and add complexity on top of it

  • starts with a paper prototype
  • next iteration: wireframe
  • then a simple design: no animations, no shadows, ...
  • and then ultimately it will be an elaborate design

there is no prescription on how we get there

sadly, UX Design happens often without the development team

detachment of business leads to improving what's already being used, instead of what could be.

this is really hard to integrate with Agile projects

if we look at System Design, how should that look like

  • understand the context of the business
  • design domain model
  • implement domain model
  • evaluate against stakeholder feedback repeat

=> it turns out somebody has already thought about that: Eric Evans, DDD

team crunches knowledge iteratively
this will take time => but we don't often allow for that

4 phases of doing UX and System Design in parallel
- phase 1: build first iteration of domain model + paper prototype
- BDD/acceptance tests
- personas
- screens
- phase 2: attach to domain core + build wireframes
- attach UI directly to the domain core: no infrastructure in between
- run on local machine to get rapid feedback
- phase 3: gradually add complexity + build simple design
- apply heuristics and techniques from software crafting
- test harness, encapsulation, single responsibility, dependency inversion, hexagonal with ports and adapters
- yagni
- no database, but hashmaps
- legacy systems are integrated with adapters
- phase 4: build elaborate design + zoom out (add all the technical layers as we need them)
- extract modules into separate apps
- introduce different databases per use cases as needed
- introduce security
- introduce chaos engineering => resilience
- ...

if you look at each component of your system as an entity, you'll realise you don't need half of the crap you usually use

This is Domain Prototyping

Why is this a case study?
because we are already doing this ...
... at an actual customer

Customer buy-in:
- we will focus on maximising learning first: they really didn't had an idea on what they wanted
First milestone (8 weeks):
- build at least one functioning prototype
- run one user test as explained by the Google runbook: we would film how 5 users used the app
- if posible sign a B2B customer
Second milestone (6 months):
- build a minimal sellable product
=> this was a big thing as their original plan was to sell a product in 2 years

mixed team of:
- 3 local consultants
- 1 internal developer
- 2 near shoring developers
- 1 UX designer
- PO+SME support from customer
- remote mob-programming
- Angular / NodeJS + TypeScript

project ramp up (2 weeks):
- we ran big picture eventstorming with 14 people
- we used the results to identify bounded contexts
- out of ~20 bounded contexts, we picked 4 to implement MSP
- we ran a 2-day lift-of workshop to create a jelled team

we're seeing results (8 weeks in, Phase I):
- we have rewritten the domain model 6 times
- we found and solved major inconsistencies
- we removed an entire bounded context because it wasn't necessary
- saved ~ 120-150k EUR
- "You're thinking as we do!" => developers think like business and actually comes with better solutions @w3ltraumpirat

  • we connected UI and domain in week 2

4 months in, Phase II
- we are always presenting a product, not a concept
- focus is still on getting business right first
- user tests (every 3-4 weeks) are giving amazing insights
- still not running a single database: still no technologies, but results

5 months in, Phase III
- did a spike (1 week long) to introduce React: we kept the same UI technology
- transitioned to eventbus/decoupled modules
- introducing roles and personas

almost 6 months in, Phase IV:
- rest api
- microservices
- deployed to Kubernetes
- upgraded deployment pipeline
all in the last month

Disclaimer: there were challenges
- team had to jell
- customer and team never worked like that
- devs gravitated towards comfort zones like fruitless efforts to keep UI/domain in sync (use the models in UI, if you know DDD, you know this is not done)
- lacking of DDD experience and crafting skills

Management worried about long term project goals/board approval (but we were able to avoid estimates).
Management thought they had no control. Although they never had. That is an illusion. @w3ltraumpirat

It [Domain Prototyping] wasn't planned: I stumpled upon the idea by accident. @w3ltraumpirat (don't we all do that ;) )