Keith Braithwaite on Domain Driven Design
0 likes662 views
The document discusses techniques for software development that are still effective despite attempts to forget them. It analyzes how IT systems would be diagnosed if they were a person, with issues like ADHD and OCD. Old techniques like structured programming and ensuring code works on the first try are examined, noting the different constraints of modern development. Domain modeling and analysis are discussed as important practices that were undervalued.
![Syntropy: Relationship Between Models
“…the main correspondence between all three
[perspectives] is in the type views for the concept
domains.” —Cook and Daniels §10.3 emphasis in
original
“State diagrams do not, in general, correspond
between essential and specification models.” —ibid
Nothing New Under the Sun
Slide 33
11 March 2010
Keith Braithwaite
© Zühlke 2010
Syntropy: The System Boundary
“If the software boundary is implicit in the situation
itself, essential modelling may not be very helpful,
because the essential model would express the
same behaviour as the specification model without
specifying which events are software-generated.
However, when the software boundary is to be
designed, an essential model provides a systematic
way of designing it.” —Cook and Daniels §10.5
Nothing New Under the Sun
Slide 34
11 March 2010
Keith Braithwaite
© Zühlke 2010
17](https://image.slidesharecdn.com/braithwaiteunerthesunddd-100427082436-phpapp02/85/Keith-Braithwaite-on-Domain-Driven-Design-17-320.jpg)
![Problem Frames
“The problem is not at the computer interface—it is
deeper into the world, further away form the
computer”—Jackson Problem Frames §1.4
“Many descriptions that aught to be about the world
[…] are really about the computer and the
software”—ibid §1.7
“Not everything worth thinking about has to result in a
piece of program text or a designed domain. And
conversely, the fact that there will be no model of
[some things] doesn’t mean that you don’t have to
describe them in your problem analysis” —ibid §2. Nothing New Under the Sun
Slide 37
11 March 2010
Keith Braithwaite
© Zühlke 2010
Problem Frame: Required Behaviour
The Control Machine, which is to be built,
directs Causal Phenomena (C1) at the Control
Controlled Domain Machine
The Controlled Domain may respond with CM!C1 CD!C2
Causal Phenomena (C2) to provide feedback
The Controlled Domain is a a Causal Domain, so Controlled
we can predict how C2 depends on C1 Domain
C
The Required Behaviour specifies some Causal
Phenomena (C3) which must be satisfied if C3
the Control Machine is to be correct Nothing New Under the Sun
Required
Slide 38
Example: timed traffic lights
11 March 2010
Behaviour
Keith Braithwaite
© Zühlke 2010
19](https://image.slidesharecdn.com/braithwaiteunerthesunddd-100427082436-phpapp02/85/Keith-Braithwaite-on-Domain-Driven-Design-19-320.jpg)
Ad
More Related Content
More from Skills Matter (20)
Recently uploaded (20)
Ad
Keith Braithwaite on Domain Driven Design
- 1. Nothing New Under the Sun Techniques that still work no matter how hard we try to forget them Nothing New Under the Sun Slide 1 21 July 2009 Keith Braithwaite © Zühlke 2010 Context “I come as an entertainer, not as a salesman. I want you to enjoy these ideas because I enjoy them”— Alan Watts Nothing New Under the Sun Slide 2 21 July 2009 Keith Braithwaite © Zühlke 2010 1
- 2. If IT were a person… It would be diagnosed with • ADHD • Retrograde amnesia • OCD Nothing New Under the Sun Slide 3 21 July 2009 Keith Braithwaite © Zühlke 2010 If IT were a person… Nothing New Under the Sun Slide 4 21 July 2009 Keith Braithwaite © Zühlke 2010 2
- 3. If IT were a person… It would be diagnosed with • ADHD – We have difficulty retaining focus on the job at hand – We are very easily distracted by • Retrograde amnesia – We don’t recall our past • OCD Nothing New Under the Sun Slide 5 21 July 2009 Keith Braithwaite © Zühlke 2010 If IT were a person… It would be diagnosed with • ADHD – We have difficulty retaining focus on the job at hand – We are very easily distracted by • Retrograde amnesia – We don’t recall our past – We don’t recall our past • OCD Nothing New Under the Sun Slide 6 21 July 2009 Keith Braithwaite © Zühlke 2010 3
- 4. If IT were a person… It would be diagnosed with • ADHD – We have difficulty retaining focus on the job at hand – We are very easily distracted by • Retrograde amnesia – We don’t recall our past – We don’t recall our past • OCD – We follow rituals independent of their effectiveness Nothing New Under the Sun Slide 7 21 July 2009 Keith Braithwaite © Zühlke 2010 If IT were a person… It would be diagnosed with • ADHD – We have difficulty retaining focus on the job at hand – We are very easily distracted by • Retrograde amnesia – We don’t recall our past – We don’t recall our past • OCD – We follow rituals independent of their effectiveness Nothing New Under the Sun Slide 8 21 July 2009 Keith Braithwaite © Zühlke 2010 4
- 5. Tony Hoare said… “If we could only learn the right lessons from the successes of the past we would not need to learn from the failures ” Nothing New Under the Sun Slide 9 21 July 2009 Keith Braithwaite © Zühlke 2010 Zombies www.flickr.com/photos/ hryckowian/3540744713/ Nothing New Under the Sun Slide 10 21 July 2009 Keith Braithwaite © Zühlke 2010 5
- 6. Zombies Given half a chance they will eat your brain • Code the works “first time” • Structured Programming These, and others, we should forget Nothing New Under the Sun Slide 11 21 July 2009 Keith Braithwaite © Zühlke 2010 Code that works “first time” City and Guilds COBOL • 3 attempts to compile, run and test or fail There was a time when this sort of thing made sense Nothing New Under the Sun Slide 12 21 July 2009 Keith Braithwaite © Zühlke 2010 6
- 7. Code that works “first time” There was a time when this sort of thing made sense Nothing New Under the Sun Slide 13 21 July 2009 Keith Braithwaite © Zühlke 2010 Code that works “first time” Jerry Weinberg tells of being told that • Thecomputer (singular) earns more than you do, so behave accordingly Nothing New Under the Sun Slide 14 21 July 2009 Keith Braithwaite © Zühlke 2010 7
- 8. Code that works “first time” The computer learns more than you, behave accordingly • cost(processor time) >> cost(developer time) • Cycle time to get feedback—hours to days Nothing New Under the Sun Slide 15 21 July 2009 Keith Braithwaite © Zühlke 2010 Code that works “first time” The computer learns more than you, behave accordingly • cost(processor time) >> cost(developer time) • Cycle time to get feedback—hours to days In fact, you earn much more than the computer Nothing New Under the Sun Slide 16 21 July 2009 Keith Braithwaite © Zühlke 2010 8
- 9. Code that works “first time” The computer learns more than you, behave accordingly • cost(processor time) >> cost(developer time) • Cycle time to get feedback—hours to days You earn much more than the computer, behave accordingly • cost(processor time) << cost(developer time) • Cycle time to get feedback—milliseconds to minutes • A top-end dev workstation amortised over 3 years – £1 per day – 2 or 3 orders of magnitude cheaper than a programmer Nothing New Under the Sun Slide 17 21 July 2009 behave accordingly Keith Braithwaite © Zühlke 2010 Code that works “first time” low Uncertainty high high ch cs ao liti s po Disagreement sim pli gy city olo Nothing New Under the Sun Slide 18 ide 21 July 2009 low Keith Braithwaite © Zühlke 2010 9
- 10. Code that works “first time” low Uncertainty high high N pr ovel ac pr ood e tic tic e ac G Disagreement Be st Pr ac e pr od tic tic Go Nothing New Under the Sun e ac Slide 19 21 July 2009 low Keith Braithwaite © Zühlke 2010 Code that works “first time” low Uncertainty high high Sense ActNo pr vel ac pr ood e tic Analyze Sense tic e ac G Disagreement Respond Respond Sense Be Sense st Pr Categorize Analyze ac e pr od tic tic Go Nothing New Under the Sun e ac Slide 20 Respond Respond 21 July 2009 low Keith Braithwaite © Zühlke 2010 10
- 11. Old School: things we got right Nothing New Under the Sun Slide 21 21 July 2009 http://commons.wikimedia.org/wiki/File:Vincent_Series_C_Black_Shadow_1950.jpg Keith Braithwaite © Zühlke 2010 Old School: things we got right Nothing New Under the Sun Slide 22 21 July 2009 Keith Braithwaite http://www.digibarn.com/collections/screenshots/xerox-star-8010/xerox-star-8010-02.jpg © Zühlke 2010 11
- 12. Old School: things we got right Analysis Architecture Modelling Nothing New Under the Sun Slide 23 21 July 2009 http://commons.wikimedia.org/wiki/File:Vincent_Series_C_Black_Shadow_1950.jpg Keith Braithwaite © Zühlke 2010 Analysis There used to be this thing called Systems Analysis • It used to be a core skill • But it got a bad name Nothing New Under the Sun Slide 24 21 July 2009 Keith Braithwaite © Zühlke 2010 12
- 13. Analysis So, we stopped doing it • Agile gave some of us an excuse Nothing New Under the Sun Slide 25 21 July 2009 Keith Braithwaite © Zühlke 2010 Analysis We had to re-invent understanding • Behaviour Driven Development – (AKA TDD the way you were always supposed to do it) • Domain Driven Design – “Until I started working in "enterprise IT" I didn't realize that people didn't do this. I suppose that this is an important book, but it's depressing that this is so”—Nat Pryce Nothing New Under the Sun Slide 26 21 July 2009 Keith Braithwaite © Zühlke 2010 13
- 14. Analysis Domain Driven Design “Leading software designers have recognized domain modeling and design as critical topics for at least 20 years, yet surprisingly little has been written about what needs to be done or how to do it.”—Evans Nothing New Under the Sun Slide 27 21 July 2009 Keith Braithwaite © Zühlke 2010 Syntropy Three Perspectives: • Essential • Specification • Implementation Three Kinds of Domain • Concept • Interaction • Infrastructure Nothing New Under the Sun Slide 28 11 March 2010 http://www.syntropy.co.uk/syntropy/designing-object-systems.pdf Keith Braithwaite © Zühlke 2010 14
- 15. Syntropy: Essential Perspective Essential models talk about • (someone’s understanding of) • (a part of) • (a situation in) The World • Objects with observable state, identity • Globally broadcast, instantaneous events • Objects change state in response to events Nothing New Under the Sun – Not “message sending” Slide 29 11 March 2010 Keith Braithwaite © Zühlke 2010 Syntropy: Specification Perspective Specification models talk about a (proposed) system “At some point during a development (which may or may not be at the beginning), the interface at the boundary between the software and its environment must be specified, and the specification model provides a way to specify this interface precisely.”—Cook and Daniels §6.1 emphasis in original • Objects with observable state, identity • Globally broadcast, instantaneous events Nothing New Under the Sun Slide 30 • Objectschange state in response to events and 11 March 2010 generate new events Keith Braithwaite © Zühlke 2010 15
- 16. Syntropy: Implementation Perspective Implementation models talk about design • Objects with observable state, identity, and responsibilities • Point-to-point messages • Objects change state in response to messages and send new messages Nothing New Under the Sun Slide 31 11 March 2010 Keith Braithwaite © Zühlke 2010 Syntropy: Domains Three kinds of domain • Interaction: at the system boundary • Concept: what the system is about • Infrastructure: How it works Essential Perspective models concentrate on concept domains Specification Perspective models have Interaction domains Kiln control system, Cook and Daniels fig 11.2 Implementation Perspective models have Nothing New Under the Sun Slide 32 all three 11 March 2010 Keith Braithwaite © Zühlke 2010 16
- 17. Syntropy: Relationship Between Models “…the main correspondence between all three [perspectives] is in the type views for the concept domains.” —Cook and Daniels §10.3 emphasis in original “State diagrams do not, in general, correspond between essential and specification models.” —ibid Nothing New Under the Sun Slide 33 11 March 2010 Keith Braithwaite © Zühlke 2010 Syntropy: The System Boundary “If the software boundary is implicit in the situation itself, essential modelling may not be very helpful, because the essential model would express the same behaviour as the specification model without specifying which events are software-generated. However, when the software boundary is to be designed, an essential model provides a systematic way of designing it.” —Cook and Daniels §10.5 Nothing New Under the Sun Slide 34 11 March 2010 Keith Braithwaite © Zühlke 2010 17
- 18. Aside: Diagnostic Instrument If everyone agrees that it’s obviously correct: • That the system has layers • The one at the “top” is a website • The one at the bottom is a database Then: • You probably don’t have much of a domain • Notethat adding an ORM layer does not magically create a domain Nothing New Under the Sun Slide 35 11 March 2010 Keith Braithwaite © Zühlke 2010 Syntropy: Implications There is no “seamlessness” • From world to spec to system requires translation You can’t sensibly use exactly one modelling language: • To understand the world • To specify a system • To design an implementation Nothing New Under the Sun Slide 36 11 March 2010 Keith Braithwaite © Zühlke 2010 18
- 19. Problem Frames “The problem is not at the computer interface—it is deeper into the world, further away form the computer”—Jackson Problem Frames §1.4 “Many descriptions that aught to be about the world […] are really about the computer and the software”—ibid §1.7 “Not everything worth thinking about has to result in a piece of program text or a designed domain. And conversely, the fact that there will be no model of [some things] doesn’t mean that you don’t have to describe them in your problem analysis” —ibid §2. Nothing New Under the Sun Slide 37 11 March 2010 Keith Braithwaite © Zühlke 2010 Problem Frame: Required Behaviour The Control Machine, which is to be built, directs Causal Phenomena (C1) at the Control Controlled Domain Machine The Controlled Domain may respond with CM!C1 CD!C2 Causal Phenomena (C2) to provide feedback The Controlled Domain is a a Causal Domain, so Controlled we can predict how C2 depends on C1 Domain C The Required Behaviour specifies some Causal Phenomena (C3) which must be satisfied if C3 the Control Machine is to be correct Nothing New Under the Sun Required Slide 38 Example: timed traffic lights 11 March 2010 Behaviour Keith Braithwaite © Zühlke 2010 19
- 20. Problem Frame: Commanded Behaviour The Control Machine and Controlled Domain interact as in Required Control Behaviour Machine Additionally an Operator observes events in OP!E4 CD!C2 the context of the Commanded CM!C1 Behaviour (such as E4) and sends commands to the control machine Operator Controlled Domain The Operator is a merely “biddable” B C domain, we cannot predict to a certainty C3 how E4 and C3 are related E4 Nothing New Under the Sun Example: opening or closing a sluicegate Commanded Slide 39 11 March 2010 under manual control Behaviour Keith Braithwaite © Zühlke 2010 Problem Frame: Information Display The Real World is a Causal Domain, but an automomous, active one. It does it’s own Information thing. It shares causal phenomena (such as Machine C1) with the Information Machine. The Information Machine sends events (E2) IM!E2 RW!C1 to the Display (also a Causal Domain) Display Real World The Display updates shared symbolic values (such as Y4) which must reflect C C phenomena C shared with the Real World, C3 but which can only be inferred from C1 Y4 Nothing New Under the Sun Example: vehicle odometer Display~Real Slide 40 11 March 2010 World Keith Braithwaite © Zühlke 2010 20
- 21. Problem Frame: Simple Workpieces The Editing Tool can send commands (in the form of events such as E1) to the work Editing pieces. Tool The workpieces are are leXical domain and US!E3 WP!Y2 may present symbolic phenomena (Y2) ET!E1 to the Editing Tool. User Work The User may send events (E3) reflecting Pieces their desires for the workpieces. B X Example: a party planning tool Y4 E3 Nothing New Under the Sun Command Slide 41 11 March 2010 Effects Keith Braithwaite © Zühlke 2010 Problem Frame: Transformation The Transform Machine notes symbolic phenomena (such as Y1) as input and Transform emits symbolic phenomena (such as Machine Y2) as output. TM!Y2 IN!Y1 Input and Output are both lexical domains. Example: email statistics analyser Outputs Inputs X X Y3 Y4 Nothing New Under the Sun IO Relation Slide 42 11 March 2010 Keith Braithwaite © Zühlke 2010 21
- 22. Problem Frames: Three Descriptions Three different things, three different descriptions • The requirement is in the world • The specification is at the system interface • The domains join them up Real problems have multiple, overlapping frames • The book contains much guidance on managing this Nothing New Under the Sun Slide 43 11 March 2010 Keith Braithwaite © Zühlke 2010 Problem Frames: The aspiration “Ideally, each problem frame would be associate with a systematic method that is known to be effective for analyzing and solving any problem that fits the frame” Nothing New Under the Sun Slide 44 11 March 2010 Keith Braithwaite © Zühlke 2010 22
- 23. Re–invention About 20 years ago a bunch of really smart people thought really hard about domains and their relationship to design. They came up with a bunch of really good ideas, and about 15 years ago, wrote them down. We had to re–invent the idea of understanding domains as a guide to building systems Are we going to have to re–discover those good ideas, too? Nothing New Under the Sun Slide 45 11 March 2010 Keith Braithwaite © Zühlke 2010 Not Doing Your Homework —Oliver Heaviside, 1884 Nothing New Under the Sun Slide 46 11 March 2010 Keith Braithwaite © Zühlke 2010 23
- 24. Not Doing Your Homework Domain Driven Design “Leading software designers have recognized domain modeling and design as critical topics for at least 20 years, yet surprisingly little has been written about what needs to be done or how to do it.”—Evans But what has been written contains valuable lessons Maybe it would be worth looking… Nothing New Under the Sun Slide 47 21 July 2009 Keith Braithwaite © Zühlke 2010 24