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