CHAPTER 1 Introduction 1
1.1 The touchstones: Lean and Agile 2
1.2 Lean Architecture and Agile Feature Development 6
1.3 Agile Production 8
1.3.1 Agile builds on Lean 9
1.3.2 The scope of Agile systems 10
1.3.3 Agile and DCI 12
1.4 The Book in a Very Small Nutshell 13
1.5 Lean and Agile: Contrasting and Complementary 14
1.5.1 The Lean Secret 17
1.6 Lost Practices 18
1.6.1 Architecture 19
1.6.2 Handling dependencies between requirements 20
1.6.3 Foundations for usability 20
1.6.4 Documentation 21
Code does not stand alone__ 23
Capturing the “why”__ 25
1.6.5 Common sense, thinking, and caring 26
1.7 What this book is not about 28
1.8 Agile, Lean— oh, yeah, and Scrum and methodologies and
such 29
1.9 History and such 31
CHAPTER 2 Agile Production in a Nutshell 35
2.1 Engage the stakeholders 36
2.2 Define the problem 38
2.3 Focusing on what the system is: the foundations of
form 39
2.4 Focusing on what the system does: the system lifeblood 42
2.5 Design and Code 44
2.6 Countdown: 3, 2, 1… 45
CHAPTER 3 Stakeholder Engagement 47
3.1 The Value Stream 48
3.1.1 End users and other stakeholders as value stream
anchors 48
3.1.2 Architecture in the value stream 50
3.1.3 The Lean Secret 51
3.2 The key stakeholders 55
3.2.1 End Users 57
Psyching out the end users__ 59
Don’t forget behavior__ 61
The end user landscape__ 62
3.2.2 The business 63
A special note for managers__ 64
3.2.3 Customers 66
… as contrasted with end users__ 66
“Customers” in the value stream__ 69
3.2.4 Domain experts 69
No ivory tower architects__ 71
Experts in both problem and solution domains__ 72
3.2.5 Developers and testers 73
3.3 Process elements of stakeholder engagement 76
3.3.1 Getting started 77
3.3.2 Customer engagement 79
3.4 The network of stakeholders: trimming wasted time 80
3.4.1 Stovepipe versus swarm 81
3.4.2 The first thing you build 84
3.4.3 Keep the team together 86
3.5 No quick fixes, but some hope 87
CHAPTER 4 Problem Definition 89
4.1 What’s Agile about problem definitions? 90
4.2 What’s Lean about problem definitions? 91
4.3 Good and bad problem definitions 92
4.4 Problems and solutions 95
4.5 The process around problem definitions 96
4.5.1 Value the hunt over the prize 97
4.5.2 Problem ownership 98
4.5.3 Creeping featurism 99
4.6 Problem definitions, goals, charters, visions, and
objectives 100
4.7 Documentation? 101
CHAPTER 5 What the System Is, Part 1: Lean
Architecture 103
5.1 Some surprises about architecture 105
5.1.1 What’s Lean about this? 107
Deliberation and “pull”__ 108
Failure-proof constraints or “poka-yoke”__ 109
The Lean mantras of conservation, consistency and focus__ 109
5.1.2 What’s Agile about architecture? 110
It’s all about individuals and interactions__ 110
Past excesses__ 111
Dispelling a couple of Agile myths__ 112
5.2 The first design step: Partitioning 114
5.2.1 The first partition: domain form versus behavioral
form 116
5.2.2 The second partitioning: Conway’s Law 117
5.2.3 The real complexity of partitioning 120
5.2.4 Dimensions of complexity 122
5.2.5 Domains: a particularly interesting partitioning 122
5.2.6 Back to dimensions of complexity 125
5.2.7 Architecture and culture 130
5.2.8 Wrap-up on Conway’s Law 131
5.3 The second design step: selecting a design style 131
5.3.1 Contrasting structuring with partitioning 133
5.3.2 The fundamentals of style: commonality and variation 135
5.3.3 Starting with tacit commonality and variation 137
5.3.4 Commonality, variation and scope 140
5.3.5 Making commonalities and variations explicit 144
Commonality categories__ 146
Next steps__ 148
5.3.6 The most common style: object orientation 148
Just what is object orientation?__ 149
5.3.7 Other styles within the Von Neumann world 152
5.3.8 Domain-specific languages and application generators 156
The state of the art in DSLs__ 156
DSLs’ place in architecture__ 157
5.3.9 Codified forms: pattern languages 158
5.3.10 Third-party software and other paradigms 160
5.4 Documentation? 164
5.4.1 The domain dictionary 165
5.4.2 Architecture carryover 166
5.5 History and such 166
CHAPTER 6 What the system Is, part 2: Coding it
up 169
6.1 The third step: the rough framing of the code 169
6.1.1 Abstract Base Classes 171
6.1.2 Pre-conditions, post-conditions, and assertions 176
Static cling__ 182
6.1.3 Algorithmic scaling: the other side of static
assertions 185
6.1.4 Form versus accessible services 187
6.1.5 Scaffolding 188
6.1.6 Testing the architecture 191
Usability Testing__ 191
Architecture testing__ 191
6.2 Relationships in architecture 195
6.2.1 Kinds of relationship 195
6.2.2 Testing the relationships 198
6.3 Not your old professor’s OO 199
6.4 How much architecture? 203
6.4.1 Balancing BUFD and YAGNI 203
6.4.2 One size does not fit all 205
6.4.3 When are you done? 207
6.5 Documentation? 208
6.6 History and such 209
CHAPTER 7 What the System Does: System
Functionality 211
7.1 What the system does 212
7.1.1 User Stories: a beginning? 212
7.1.2 Enabling specifications and use cases 214
7.1.3 Helping developers, too 217
7.1.4 Your mileage may vary 218
7.2 Who is going to use our software? 219
7.2.1 User Profiles 219
7.2.2 Personas 220
7.2.3 User Profiles or Personas? 220
7.2.4 User Roles and Terminology 221
7.3 What do the users want to use our software for? 222
7.3.1 Feature Lists 222
7.3.2 Dataflow diagrams 223
7.3.3 Personas and scenarios 223
7.3.4 Narratives 224
7.3.5 Behavior-driven development 224
7.3.6 Now that we’re warmed up… 225
Prototypes__ 225
Towards foundations for decisions__ 226
Known and unknown unknowns__ 226
Use cases as a decision framework__ 227
7.4 Why does the user want to use our software? 227
7.5 Consolidation of what the system does 229
7.5.1 The helicopter view 232
Habits: the developer view and the user view__ 234
Trimming the scope__ 238
7.5.2 Setting the stage 239
7.5.3 Play the sunny day scenario 241
Business Rules__ 246
7.5.4 Add the interesting stuff 249
7.5.5 Use cases to roles 258
Roles from the use case__ 258
Bridging the gap between the business and the programmer__ 259
7.6 Recap 261
7.6.1 Support the user’s workflow 261
7.6.2 Support test close to development 261
7.6.3 Support efficient decision-making about functionality 262
7.6.4 Support emerging requirements 263
7.6.5 Support release planning 263
7.6.6 Support sufficient input to the architecture 264
7.6.7 Support the team’s understanding of what to develop 264
7.7 “It Depends”: When use cases are a bad fit 265
7.7.1 Classic OO: Atomic Event Architectures 266
7.8 Usability testing 268
7.9 Documentation? 269
7.10 History and Such 271
CHAPTER 8 Coding It Up: Basic Assembly 275
8.1 The big picture: Model-View-Controller-User 276
8.1.1 What is a program? 276
8.1.2 What is an Agile program? 278
8.1.3 MVC in more detail 280
8.1.4 MVC-U: Not the end of the story. 281
A short history of computer science__ 281
Atomic Event Architectures__ 284
DCI architectures__ 285
8.2 The form and architecture of atomic event systems 285
8.2.1 Domain objects 286
8.2.2 Object Roles, interfaces and the Model 287
Example__ 289
8.2.3 Reflection: use cases, atomic event architectures, and
algorithms 291
8.2.4 A special case: One-to-many mapping of object roles to
objects 292
8.3 Updating the domain logic: method elaboration,
factoring, and re-factoring 293
8.3.1 Creating new classes and filling in existing function
placeholders 294
Example__ 295
8.3.2 Back to the future: this is just good old-fashioned OO 296
8.3.3 Tools 297
8.3.4 Factoring 299
8.3.5 A caution about re-factoring 299
8.4 Documentation? 300
8.5 Why all these artifacts? 300
8.6 History and such 301
CHAPTER 9 Coding it Up: the DCI Architecture 303
9.1 Sometimes, smart objects just aren’t enough 303
9.2 DCI in a nutshell 304
9.3 Overview of DCI 307
9.3.1 Parts of the user mental model we’ve forgotten 308
9.3.2 Enter methodful object roles 310
9.3.3 Tricks with traits 313
9.3.4 Context classes: one per use case 313
9.4 DCI by example 318
9.4.1 The inputs to the design 318
9.4.2 Use cases to algorithms 319
9.4.3 Methodless object roles: the framework for identifiers 324
9.4.4 Partitioning the algorithms across methodful object
roles 327
Traits as a Building Block__ 327
In Smalltalk__ 328
In C++__ 328
In Ruby__ 330
Coding it up: C++__ 332
Coding up DCI in Ruby__ 335
9.4.5 The Context framework 336
The Ruby code__ 338
The C++ code__ 341
Making contexts work__ 344
Habits: Nested Contexts in Methodful Object roles__ 356
9.4.6 Variants and Tricks in DCI 363
Context layering__ 363
Information hiding__ 363
Selective object role injection__ 364
9.5 Updating the domain logic 366
9.5.1 Contrasting DCI with the atomic event style 366
9.5.2 Special considerations for domain logic in DCI 368
9.6 Context objects in the user mental model: Solution to
an age-old problem 372
9.7 Why all these artifacts? 377
Why not use classes instead of “methodful object roles”?__ 378
Why not put the entire algorithm inside of the class with which it is most
closely coupled?__ 379
Then why not localize the algorithm to a class and tie it to domain
objects as needed?__ 379
Why not put the algorithm into a procedure, and combine the procedural
paradigm with the object paradigm in a single program?__ 379
If I collect together the algorithm code for a use case in one class,
including the code for all of its deviations, doesn’t the Context become very
large?’__ 380
So, what do DCI and lean architecture give me?__ 380
And remember…__ 381
9.8 Beyond C++: DCI in other languages 381
9.8.1 Scala 382
9.8.2 Python 383
9.8.3 C# 383
9.8.4 … and even Java 384
9.8.5 The account example in Smalltalk 384
9.9 Documentation? 384
9.10 History and such 386
9.10.1 DCI and aspect-oriented programming 387
9.10.2 Other approaches 388
CHAPTER 10 Epilog 389
APPENDIX A Scala Implementation of the DCI Account Example 391
APPENDIX B Account example in Python 395
APPENDIX C Account example in C# 399
APPENDIX D Account example in Ruby 405
APPENDIX E Qi4j 412
APPENDIX F Account example in Squeak 415
F.1 Testing perspective 417
F.2 Data perspective 418
F.2.1 BB5Bank 418
F.2.2 BB5SavingsAccount 418
F.2.3 BB5CheckingAccount 419
F.3 Context perspective 419
F.3.1 BB5MoneyTransferContext 420
F.4 Interaction (RoleTrait) perspective 421
F.4.1 BB5MoneyTransferContextTransferMoneySource 421
F.4.2 BB5MoneyTransferContextMyContext 422
F.4.3 BB5MoneyTransferContextTransferMoneySink 422
F.5 Support perspective (Infrastructure classes) 422
F.5.1 BB1Context (Common superclass for all contexts) 422
F.5.2 BB1RoleTrait (All RoleTraits are instances of this
class) 424
Bibliography______ 425