Lean Architecture

James O. Coplien is a writer, lecturer, and researcher in the field of Computer Science. He has made key contributions in the areas of software design and organizational development, software debugging, and in empirical research. His early work on C++ idioms was one of the three primary sources of the popular Design Patterns. His work on Organizational patterns was an inspiration for both Extreme Programming and for Scrum. Cope was a founding Member of Hillside Group with Kent Beck, Grady Booch, Ward Cunningham, Ralph Johnson, Ken Auer and Hal Hildebrand. He is responsible for starting up several of the conferences in the Pattern Languages of Programming (PLoP) conference series and is a longstanding pattern author and PLoP shepherd. Gertrud Bjornvig is an experienced software consultant and trainer and has been in software development since 1984. She's been working on development teams as a developer, analyst, and project manager, and has had cross-organizational roles as methodologist and process consultant. Her background is in object-oriented development, including extensive work with UML and RUP. Gertrud has been employed by Enator, Navision, Microsoft, and TietoEnator, but since June 2007 she has been independent as a part of Gertrud & Cope.Gertrud holds a Master in Computer Science and Communication and is one of the founders of Danish Agile User Group.

• About the Authors xiiPreface xiii1 Introduction 11.1 The Touchstones: Lean and Agile 11.2 Lean Architecture and Agile Feature Development 41.3 Agile Production 71.3.1 Agile Builds on Lean 71.3.2 The Scope of Agile Systems 81.3.3 Agile and DCI 91.4 The Book in a Very Small Nutshell 101.5 Lean and Agile: Contrasting and Complementary 111.5.1 The Lean Secret 141.6 Lost Practices 141.6.1 Architecture 151.6.2 Handling Dependencies between Requirements 151.6.3 Foundations for Usability 161.6.4 Documentation 16Code Does Not Stand Alone 17Capturing the ‘‘Why’’ 191.6.5 Common Sense, Thinking, and Caring 191.7 What this Book is Not About 211.8 Agile, Lean – Oh, Yeah, and Scrum and Methodologies and Such 221.9 History and Such 242 Agile Production in a Nutshell 272.1 Engage the Stakeholders 272.2 Define the Problem 292.3 Focusing on What the System Is: The Foundations of Form 302.4 Focusing on What the System Does: The System Lifeblood 322.5 Design and Code 332.6 Countdown: 3, 2, 1. . . 343 Stakeholder Engagement 353.1 The Value Stream 353.1.1 End Users and Other Stakeholders as Value Stream Anchors 363.1.2 Architecture in the Value Stream 373.1.3 The Lean Secret 383.2 The Key Stakeholders 413.2.1 End Users 43Psyching Out the End Users 44Don’t Forget Behavior 46The End User Landscape 473.2.2 The Business 47A Special Note for Managers 483.2.3 Customers 50. . . As Contrasted with End Users 50‘‘Customers’’ in the Value Stream 523.2.4 Domain Experts 52No Ivory Tower Architects 53Experts in Both Problemand Solution Domains 543.2.5 Developers and Testers 553.3 Process Elements of Stakeholder Engagement 573.3.1 Getting Started 583.3.2 Customer Engagement 603.4 The Network of Stakeholders: Trimming Wasted Time 613.4.1 Stovepipe Versus Swarm 613.4.2 The First Thing You Build 643.4.3 Keep the Team Together 653.5 No Quick Fixes, but Some Hope 664 Problem Definition 674.1 What’s Agile about Problem Definitions? 684.2 What’s Lean about Problem Definitions? 684.3 Good and Bad Problem Definitions 704.4 Problems and Solutions 724.5 The Process Around Problem Definitions 734.5.1 Value the Hunt Over the Prize 734.5.2 Problem Ownership 744.5.3 Creeping Featurism 754.6 Problem Definitions, Goals, Charters, Visions, and Objectives 764.7 Documentation? 775 What the System Is, Part 1: Lean Architecture 795.1 Some Surprises about Architecture 805.1.1 What’s Lean about This? 82Deliberation and ‘‘Pull’’ 83Failure-Proof Constraints or Poka-Yoke 83The Lean Mantras of Conservation, Consistency, and Focus 845.1.2 What’s Agile about Architecture? 84It’s All About Individuals and Interactions 84Past Excesses 85Dispelling a Couple of Agile Myths 865.2 The First Design Step: Partitioning 885.2.1 The First Partition: Domain Form Versus Behavioral Form 895.2.2 The Second Partitioning: Conway’s Law 905.2.3 The Real Complexity of Partitioning 935.2.4 Dimensions of Complexity 945.2.5 Domains: A Particularly Interesting Partitioning 945.2.6 Back to Dimensions of Complexity 965.2.7 Architecture and Culture 1005.2.8 Wrap-Up on Conway’s Law 1005.3 The Second Design Step: Selecting a Design Style 1005.3.1 Contrasting Structuring with Partitioning 1025.3.2 The Fundamentals of Style: Commonality and Variation 1045.3.3 Starting with Tacit Commonality and Variation 1055.3.4 Commonality, Variation, and Scope 1085.3.5 Making Commonalities and Variations Explicit 111Commonality Categories 112Next Steps 1145.3.6 The Most Common Style: Object Orientation 114Just What is Object Orientation? 1155.3.7 Other Styles within the Von NeumannWorld 1175.3.8 Domain-Specific Languages and Application Generators 120The State of the Art in DSLs 121DSLs’ Place in Architecture 1215.3.9 Codified Forms: Pattern Languages 1225.3.10 Third-Party Software and Other Paradigms 1245.4 Documentation? 1275.4.1 The Domain Dictionary 1285.4.2 Architecture Carryover 1285.5 History and Such 1296 What the System Is, Part 2: Coding It Up 1316.1 The Third Step: The Rough Framing of the Code 1316.1.1 Abstract Base Classes 1336.1.2 Pre-Conditions, Post-Conditions, and Assertions 137Static Cling 1426.1.3 Algorithmic Scaling: The Other Side of Static Assertions 1446.1.4 Form Versus Accessible Services 1466.1.5 Scaffolding 1476.1.6 Testing the Architecture 149Usability Testing 149Architecture Testing 1496.2 Relationships in Architecture 1536.2.1 Kinds of Relationship 1536.2.2 Testing the Relationships 1556.3 Not Your Old Professor’s OO 1556.4 How much Architecture? 1596.4.1 Balancing BUFD and YAGNI 1596.4.2 One Size Does Not Fit All 1606.4.3 When Are You Done? 1606.5 Documentation? 1626.6 History and Such 1637 What the System Does: System Functionality 1657.1 What the System Does 1667.1.1 User Stories: A Beginning 1667.1.2 Enabling Specifications and Use Cases 1677.1.3 Helping Developers, Too 1697.1.4 Your Mileage may Vary 1707.2 Who is Going to Use Our Software? 1717.2.1 User Profiles 1717.2.2 Personas 1717.2.3 User Profiles or Personas? 1727.2.4 User Roles and Terminology 1737.3 What do the Users Want to Use Our Software for? 1737.3.1 Feature Lists 1737.3.2 Dataflow Diagrams 1747.3.3 Personas and Scenarios 1747.3.4 Narratives 1747.3.5 Behavior-Driven Development 1757.3.6 Now that We’re Warmed Up. . . 175Prototypes 176Towards Foundations for Decisions 176Known and Unknown Unknowns 176Use Cases as a Decision Framework 1777.4 Why Does the User Want to Use Our Software? 1777.5 Consolidation of What the System Does 1787.5.1 The Helicopter View 181Habits: The Developer View and the User View 182Trimming the Scope 1857.5.2 Setting the Stage 1867.5.3 Play the Sunny Day Scenario 187Business Rules 1917.5.4 Add the Interesting Stuff 1937.5.5 Use Cases to Roles 200Roles from the Use Case 201Bridging the Gap between the Business and the Programmer 2027.6 Recap 2037.6.1 Support the User’s Workflow 2037.6.2 Support Testing Close to Development 2037.6.3 Support Efficient Decision-Making about Functionality 2047.6.4 Support Emerging Requirements 2047.6.5 Support Release Planning 2047.6.6 Support Sufficient Input to the Architecture 2057.6.7 Support the Team’s Understanding of What to Develop 2057.7 ‘‘It Depends’’: When Use Cases are a Bad Fit 2067.7.1 Classic OO: Atomic Event Architectures 2067.8 Usability Testing 2087.9 Documentation? 2097.10 History and Such 2118 Coding It Up: Basic Assembly 2138.1 The Big Picture: Model-View-Controller-User 2148.1.1 What is a Program? 2148.1.2 What is an Agile Program? 2158.1.3 MVC in More Detail 2178.1.4 MVC-U: Not the End of the Story 217A Short History of Computer Science 218Atomic Event Architectures 219DCI Architectures 2208.2 The Form and Architecture of Atomic Event Systems 2208.2.1 Domain Objects 2218.2.2 Object Roles, Interfaces, and the Model 221Example 2238.2.3 Reflection: Use Cases, Atomic Event Architectures, and Algorithms 2248.2.4 A Special Case: One-to-Many Mapping of Object Roles to Objects 2258.3 Updating the Domain Logic: Method Elaboration, Factoring, and Re-factoring 2268.3.1 Creating New Classes and Filling in Existing Function Placeholders 227Example 2288.3.2 Back to the Future: This is Just Good Old-Fashioned OO 2298.3.3 Analysis and Design Tools 2298.3.4 Factoring 2318.3.5 A Caution about Re-Factoring 2318.4 Documentation? 2318.5 Why All These Artifacts? 2328.6 History and Such 2339 Coding it Up: The DCI Architecture 2359.1 Sometimes, Smart Objects Just Aren’t Enough 2359.2 DCI in a Nutshell 2369.3 Overview of DCI 2389.3.1 Parts of the User Mental Model We’ve Forgotten 2399.3.2 Enter Methodful Object Roles 2409.3.3 Tricks with Traits 2429.3.4 Context Classes: One Per Use Case 2439.4 DCI by Example 2469.4.1 The Inputs to the Design 2469.4.2 Use Cases to Algorithms 2479.4.3 Methodless Object Roles: The Framework for Identifiers 2509.4.4 Partitioning the Algorithms Across Methodful Object Roles 253Traits as a Building Block 253In Smalltalk 253In C++ 254In Ruby 256Coding it Up: C++ 257Coding Up DCI in Ruby 2599.4.5 The Context Framework 261The Ruby Code 263The C++ Code 265Making ContextsWork 267Habits: Nested Contexts in Methodful Object Roles 2779.4.6 Variants and Tricks in DCI 283Context Layering 283Information Hiding 283Selective Object Role Injection 2849.5 Updating the Domain Logic 2859.5.1 Contrasting DCI with the Atomic Event Style 2869.5.2 Special Considerations for Domain Logic in DCI 2879.6 Context Objects in the User Mental Model: Solution to an Age-Old Problem 2909.7 Why All These Artifacts? 294Why not Use Classes Instead of ‘‘Methodful Object Roles’’? 295Why not Put the Entire Algorithm Inside of the Class withwhich it is Most Closely Coupled? 295Then Why not Localize the Algorithm to a Class and Tie it to Domain Objects as Needed? 296Why not Put the Algorithm into a Procedure, and Combine the Procedural Paradigm with the Object Paradigm in a Single Program? 296If 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? 296So, What do DCI and Lean Architecture Give Me? 297And Remember. . . 2979.8 Beyond C++: DCI in Other Languages 2979.8.1 Scala 2989.8.2 Python 2999.8.3 C# 2999.8.4 . . . and Even Java 2999.8.5 The Account Example in Smalltalk 3009.9 Documentation? 3009.10 History and Such 3019.10.1 DCI and Aspect-Oriented Programming 3029.10.2 Other Approaches 30210 Epilog 305Appendix A Scala Implementation of the DCI Account Example 307Appendix B Account Example in Python 311Appendix C Account Example in C# 315Appendix D Account Example in Ruby 321Appendix E Qi4j 327Appendix F Account Example in Squeak 331F.1 Testing Perspective 333F.2 Data Perspective 333F.2.1 BB5Bank 333F.2.2 BB5SavingsAccount 334F.2.3 BB5CheckingAccount 334F.3 Context Perspective 335F.3.1 BB5MoneyTransferContext 335F.4 Interaction (RoleTrait) Perspective 336F.4.1 BB5MoneyTransferContextTransferMoneySource 336F.4.2 BB5MoneyTransferContextMyContext 337F.4.3 BB5MoneyTransferContextTransferMoneySink 337F.5 Support Perspective (Infrastructure Classes) 337F.5.1 BB1Context (common superclass for all contexts) 337F.5.2 BB1RoleTrait (all RoleTraits are instances of this class) 339Bibliography 341Index 351

"... a book of advice that is broad, enabling, and concrete." (Lean Magazine, January 2010)