Lean Architecture for Agile Software Development

Size: px

Start display at page:

Download "Lean Architecture for Agile Software Development"

Noah Summers
5 years ago
Views:

3 Lean Architecture for Agile Software Development James Coplien Gertrud Bjørnvig A John Wiley and Sons, Ltd, Publication

4 This edition first published James Coplien and Gertrud Bjørnvig Registered office John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act Reprinted with corrections December 2010 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding that the publisher is not engaged in rendering professional services. If professional advice or other expert assistance is required, the services of a competent professional should be sought. Quotes from The Clock of the Long Now: Time and Responsibility The Ideas Behind the World s Slowest Computer are Copyright 2000 Stewart Brand. Reprinted by permission of Basic Books, a member of the Perseus Books Group. A catalogue record for this book is available from the British Library. ISBN Typeset in 11/13 Palatino by Laserwords Private Limited, Chennai, India. Printed in Great Britain by TJ International, Padstow, Cornwall

5 Dedication To Trygve Mikkjel Heyerdahl Reenskaug, also a grandfather

6 Publisher s Acknowledgments Some of the people who helped bring this book to market include the following: Editorial and Production VP Consumer and Technology Publishing Director: Michelle Leete Associate Director Book Content Management: Martin Tribe Associate Publisher: Chris Webb Executive Commissioning Editor: Birgit Gruber Assistant Editor: Colleen Goldring Publishing Assistant: Ellie Scott Project Editor: Juliet Booker Content Editor: Nicole Burnett Copy Editor: Richard Walshe Marketing: Senior Marketing Manager: Louise Breinholt Marketing Executive: Kate Batchelor Composition Services: Compositor: Laserwords Private Limited, Chennai, India Proof Reader: Alex Grey Indexer: Annette Musker

7 Contents About the Authors Preface 1 Introduction The Touchstones: Lean and Agile Lean Architecture and Agile Feature Development Agile Production Agile Builds on Lean The Scope of Agile Systems Agile and DCI The Book in a Very Small Nutshell Lean and Agile: Contrasting and Complementary The Lean Secret Lost Practices Architecture Handling Dependencies between Requirements Foundations for Usability Documentation 16 Code Does Not Stand Alone 17 Capturing the Why Common Sense, Thinking, and Caring What this Book is Not About Agile, Lean Oh, Yeah, and Scrum and Methodologies and Such History and Such 24 2 Agile Production in a Nutshell Engage the Stakeholders Define the Problem Focusing on What the System Is: The Foundations of Form Focusing on What the System Does: The System Lifeblood Design and Code Countdown: 3, 2, xii xiii v

8 vi Contents 3 Stakeholder Engagement The Value Stream End Users and Other Stakeholders as Value Stream Anchors Architecture in the Value Stream The Lean Secret The Key Stakeholders End Users 43 Psyching Out the End Users 44 Don t Forget Behavior 46 The End User Landscape The Business 47 A Special Note for Managers Customers 50...As Contrasted with End Users 50 Customers in the Value Stream Domain Experts 52 No Ivory Tower Architects 53 Experts in Both Problem and Solution Domains Developers and Testers Process Elements of Stakeholder Engagement Getting Started Customer Engagement The Network of Stakeholders: Trimming Wasted Time Stovepipe Versus Swarm The First Thing You Build Keep the Team Together No Quick Fixes, but Some Hope 66 4 Problem Definition What s Agile about Problem Definitions? What s Lean about Problem Definitions? Good and Bad Problem Definitions Problems and Solutions The Process Around Problem Definitions Value the Hunt Over the Prize Problem Ownership Creeping Featurism Problem Definitions, Goals, Charters, Visions, and Objectives Documentation? 77 5 What the System Is, Part 1: Lean Architecture Some Surprises about Architecture What s Lean about This? 82 Deliberation and Pull 83 Failure-Proof Constraints or Poka-Yoke 83 The Lean Mantras of Conservation, Consistency, and Focus What s Agile about Architecture? 84 It s All About Individuals and Interactions 84

9 Contents vii Past Excesses 85 Dispelling a Couple of Agile Myths The First Design Step: Partitioning The First Partition: Domain Form Versus Behavioral Form The Second Partitioning: Conway s Law The Real Complexity of Partitioning Dimensions of Complexity Domains: A Particularly Interesting Partitioning Back to Dimensions of Complexity Architecture and Culture Wrap-Up on Conway s Law The Second Design Step: Selecting a Design Style Contrasting Structuring with Partitioning The Fundamentals of Style: Commonality and Variation Starting with Tacit Commonality and Variation Commonality, Variation, and Scope Making Commonalities and Variations Explicit 111 Commonality Categories 112 Next Steps The Most Common Style: Object Orientation 114 Just What is Object Orientation? Other Styles within the Von Neumann World Domain-Specific Languages and Application Generators 120 The State of the Art in DSLs 121 DSLs Place in Architecture Codified Forms: Pattern Languages Third-Party Software and Other Paradigms Documentation? The Domain Dictionary Architecture Carryover History and Such What the System Is, Part 2: Coding It Up The Third Step: The Rough Framing of the Code Abstract Base Classes Pre-Conditions, Post-Conditions, and Assertions 137 Static Cling Algorithmic Scaling: The Other Side of Static Assertions Form Versus Accessible Services Scaffolding Testing the Architecture 149 Usability Testing 149 Architecture Testing Relationships in Architecture Kinds of Relationship Testing the Relationships Not Your Old Professor s OO How much Architecture? 159

10 viii Contents Balancing BUFD and YAGNI One Size Does Not Fit All When Are You Done? Documentation? History and Such What the System Does: System Functionality What the System Does User Stories: A Beginning Enabling Specifications and Use Cases Helping Developers, Too Your Mileage may Vary Who is Going to Use Our Software? User Profiles Personas User Profiles or Personas? User Roles and Terminology What do the Users Want to Use Our Software for? Feature Lists Dataflow Diagrams Personas and Scenarios Narratives Behavior-Driven Development Now that We re Warmed Up Prototypes 176 Towards Foundations for Decisions 176 Known and Unknown Unknowns 176 Use Cases as a Decision Framework Why Does the User Want to Use Our Software? Consolidation of What the System Does The Helicopter View 181 Habits: The Developer View and the User View 182 Trimming the Scope Setting the Stage Play the Sunny Day Scenario 187 Business Rules Add the Interesting Stuff Use Cases to Roles 200 Roles from the Use Case 201 Bridging the Gap between the Business and the Programmer Recap Support the User s Workflow Support Testing Close to Development Support Efficient Decision-Making about Functionality Support Emerging Requirements Support Release Planning Support Sufficient Input to the Architecture Support the Team s Understanding of What to Develop 205

11 Contents ix 7.7 It Depends : When Use Cases are a Bad Fit Classic OO: Atomic Event Architectures Usability Testing Documentation? History and Such Coding It Up: Basic Assembly The Big Picture: Model-View-Controller-User What is a Program? What is an Agile Program? MVC in More Detail MVC-U: Not the End of the Story 217 A Short History of Computer Science 218 Atomic Event Architectures 219 DCI Architectures The Form and Architecture of Atomic Event Systems Domain Objects Object Roles, Interfaces, and the Model 221 Example Reflection: Use Cases, Atomic Event Architectures, and Algorithms A Special Case: One-to-Many Mapping of Object Roles to Objects Updating the Domain Logic: Method Elaboration, Factoring, and Re-factoring Creating New Classes and Filling in Existing Function Placeholders 227 Example Back to the Future: This is Just Good Old-Fashioned OO Analysis and Design Tools Factoring A Caution about Re-Factoring Documentation? Why All These Artifacts? History and Such Coding it Up: The DCI Architecture Sometimes, Smart Objects Just Aren t Enough DCI in a Nutshell Overview of DCI Parts of the User Mental Model We ve Forgotten Enter Methodful Object Roles Tricks with Traits Context Classes: One Per Use Case DCI by Example The Inputs to the Design Use Cases to Algorithms Methodless Object Roles: The Framework for Identifiers 250

12 x Contents Partitioning the Algorithms Across Methodful Object Roles 253 Traits as a Building Block 253 In Smalltalk 253 In C In Ruby 256 Coding it Up: C Coding Up DCI in Ruby The Context Framework 261 The Ruby Code 263 The C++ Code 265 Making Contexts Work 267 Habits: Nested Contexts in Methodful Object Roles Variants and Tricks in DCI 283 Context Layering 283 Information Hiding 283 Selective Object Role Injection Updating the Domain Logic Contrasting DCI with the Atomic Event Style Special Considerations for Domain Logic in DCI Context Objects in the User Mental Model: Solution to an Age-Old Problem Why All These Artifacts? 294 Why not Use Classes Instead of Methodful Object Roles? 295 Why not Put the Entire Algorithm Inside of the Class with which it is Most Closely Coupled? 295 Then Why not Localize the Algorithm to a Class and Tie it to Domain Objects as Needed? 296 Why not Put the Algorithm into a Procedure, and Combine the Procedural Paradigm with the Object Paradigm in a Single Program? 296 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? 296 So, What do DCI and Lean Architecture Give Me? 297 And Remember Beyond C++: DCI in Other Languages Scala Python C# and Even Java The Account Example in Smalltalk Documentation? History and Such DCI and Aspect-Oriented Programming Other Approaches 302

13 Contents xi 10 Epilog 305 Appendix A Scala Implementation of the DCI Account Example Appendix B Account Example in Python Appendix C Account Example in C# Appendix D Account Example in Ruby Appendix E Qi4j Appendix F Account Example in Squeak 331 F.1 Testing Perspective 333 F.2 Data Perspective 333 F.2.1 BB5Bank 333 F.2.2 BB5SavingsAccount 334 F.2.3 BB5CheckingAccount 334 F.3 Context Perspective 335 F.3.1 BB5MoneyTransferContext 335 F.4 Interaction (RoleTrait) Perspective 336 F.4.1 BB5MoneyTransferContextTransferMoneySource 336 F.4.2 BB5MoneyTransferContextMyContext 337 F.4.3 BB5MoneyTransferContextTransferMoneySink 337 F.5 Support Perspective (Infrastructure Classes) 337 F.5.1 BB1Context (common superclass for all contexts) 337 F.5.2 BB1RoleTrait (all RoleTraits are instances of this class) 339 Bibliography Index

14 About the Authors Gertrud Bjørnvig is an agile requirements expert with over 20 years experience in system development. She is a co-founder of the Danish Agile User Group and is a partner in Scrum Training Institute. Jim Coplien is a software industry pioneer in object-oriented design, architecture patterns, and agile software development. He has authored several books on software design and agile software development, and is a partner in the Scrum Training Institute. xii

15 Preface What my grandfather did was create options. He worked hard to allow my father to have a better education than he did, and in turn my father did the same. Danny Hillis, quoted in The Clock of the Long Now, p Harry Grinnell, who was co-author James Coplien s grandfather, was a life-long postal worker, but many of his life s accomplishments can be found in his avocations. His father was an alcoholic and his mother a long-suffering religious woman. Grandpa Harry dropped out of school after eighth year to take a job in a coal yard to put food on the table after much of the family budget had gone to support his father s habit. Harry would go on to take up a job as a postal worker in 1925 at the age of 19, and married Jim s grandmother the next year. He faced the changes of the Great Depression, of two world wars, and of great economic and social change. You re probably wondering why an Agile book starts with a story about Grandpa Harry. It s because his avocation as a master craftsman in woodworking together with his common-sense approach to life offer a fitting metaphor for the Agile and Lean styles of development. This is a book about common sense. Of course, one person s common sense is another one s revelation. If you are just learning about Agile and Lean, or are familiar only with their pop versions, you may find new insights here. Even if you know about Agile and Lean and are familiar with architecture, you re likely to learn from this book about how the two ideas can work and play together. As a postal employee, Grandpa Harry of course worked to assure that the post office met its business objectives. He worked in the days when the U.S. postal service was still nationalized; the competition of UPS and DHL didn t threaten postal business until late in his career. Therefore, the focus of his work wasn t as much on business results and profit as it was on quality and individual customer service. Grandpa Harry was a rural mail carrier who delivered to rural Wisconsin farmers, one mailbox at a time, six days a week, come rain or shine. It wasn t unusual for him to encounter xiii

RFID HANDBOOK THIRD EDITION

RFID HANDBOOK THIRD EDITION RFID HANDBOOK FUNDAMENTALS AND APPLICATIONS IN CONTACTLESS SMART CARDS, RADIO FREQUENCY IDENTIFICATION AND NEAR-FIELD COMMUNICATION, THIRD EDITION Klaus Finkenzeller Giesecke