book

Lean Architecture for Agile Software Development

by James Coplien, Gertrud Bjørnvig

August 2010

Intermediate to advanced

376 pages

10h 6m

English

Wiley

Read now

Unlock full access

1.1. The Touchstones: Lean and Agile1.2. Lean Architecture and Agile Feature Development1.3. Agile Production1.3.1. Agile Builds on Lean1.3.2. The Scope of Agile Systems1.3.3. Agile and DCI1.4. The Book in a Very Small Nutshell1.5. Lean and Agile: Contrasting and Complementary1.5.1. The Lean Secret1.6. Lost Practices1.6.1. Architecture1.6.2. Handling Dependencies between Requirements1.6.3. Foundations for Usability1.6.4. Documentation1.6.4.1. Code Does Not Stand Alone1.6.4.2. Capturing the "Why"1.6.5. Common Sense, Thinking, and Caring1.7. What this Book is Not About1.8. Agile, Lean — Oh, Yeah, and Scrum and Methodologies and Such1.9. History and Such
2.1. Engage the Stakeholders2.2. Define the Problem2.3. Focusing on What the System Is: The Foundations of Form2.4. Focusing on What the System Does: The System Lifeblood2.5. Design and Code2.6. Countdown: 3, 2, 1 . . .
3.1. The Value Stream3.1.1. End Users and Other Stakeholders as Value Stream Anchors3.1.2. Architecture in the Value Stream3.1.3. The Lean Secret3.2. The Key Stakeholders3.2.1. End Users3.2.1.1. Psyching Out the End Users3.2.1.2. Don't Forget Behavior3.2.1.3. The End User Landscape3.2.2. The Business3.2.2.1. A Special Note for Managers3.2.3. Customers3.2.3.1. ...As Contrasted with End Users3.2.3.2. "Customers" in the Value Stream3.2.4. Domain Experts3.2.4.1. No Ivory Tower Architects3.2.4.2. Experts in Both Problem and Solution Domains3.2.5. Developers and Testers3.3. Process Elements of Stakeholder Engagement3.3.1. Getting Started3.3.2. Customer Engagement3.4. The Network of Stakeholders: Trimming Wasted Time3.4.1. Stovepipe Versus Swarm3.4.2. The First Thing You Build3.4.3. Keep the Team Together3.5. No Quick Fixes, but Some Hope
4.1. What's Agile about Problem Definitions?4.2. What's Lean about Problem Definitions?4.3. Good and Bad Problem Definitions4.4. Problems and Solutions4.5. The Process Around Problem Definitions4.5.1. Value the Hunt Over the Prize4.5.2. Problem Ownership4.5.3. Creeping Featurism4.6. Problem Definitions, Goals, Charters, Visions, and Objectives4.7. Documentation?
5.1. Some Surprises about Architecture5.1.1. What's Lean about This?5.1.1.1. Deliberation and "Pull"5.1.1.2. Failure-Proof Constraints or Poka-Yoke5.1.1.3. The Lean Mantras of Conservation, Consistency, and Focus5.1.2. What's Agile about Architecture?5.1.2.1. It's All About Individuals and Interactions5.1.2.2. Past Excesses5.1.2.3. Dispelling a Couple of Agile Myths5.2. The First Design Step: Partitioning5.2.1. The First Partition: Domain Form Versus Behavioral Form5.2.2. The Second Partitioning: Conway's Law5.2.3. The Real Complexity of Partitioning5.2.4. Dimensions of Complexity5.2.5. Domains: A Particularly Interesting Partitioning5.2.6. Back to Dimensions of Complexity5.2.7. Architecture and Culture5.2.8. Wrap-Up on Conway's Law5.3. The Second Design Step: Selecting a Design Style5.3.1. Contrasting Structuring with Partitioning5.3.2. The Fundamentals of Style: Commonality and Variation5.3.3. Starting with Tacit Commonality and Variation5.3.4. Commonality, Variation, and Scope5.3.5. Making Commonalities and Variations Explicit5.3.5.1. Commonality Categories5.3.5.2. Next Steps5.3.6. The Most Common Style: Object Orientation5.3.6.1. Just What is Object Orientation?5.3.7. Other Styles within the Von Neumann World5.3.8. Domain-Specific Languages and Application Generators5.3.8.1. The State of the Art in DSLs5.3.8.2. DSLs' Place in Architecture5.3.9. Codified Forms: Pattern Languages5.3.10. Third-Party Software and Other Paradigms5.4. Documentation?5.4.1. The Domain Dictionary5.4.2. Architecture Carryover5.5. History and Such
6.1. The Third Step: The Rough Framing of the Code6.1.1. Abstract Base Classes6.1.2. Pre-Conditions, Post-Conditions, and Assertions6.1.2.1. Static Cling6.1.3. Algorithmic Scaling: The Other Side of Static Assertions6.1.4. Form Versus Accessible Services6.1.5. Scaffolding6.1.6. Testing the Architecture6.1.6.1. Usability Testing6.1.6.2. Architecture Testing6.2. Relationships in Architecture6.2.1. Kinds of Relationship6.2.2. Testing the Relationships6.3. Not Your Old Professor's OO6.4. How much Architecture?6.4.1. Balancing BUFD and YAGNI6.4.2. One Size Does Not Fit All6.4.3. When Are You Done?6.5. Documentation?6.6. History and Such

7.1. What the System Does7.1.1. User Stories: A Beginning7.1.2. Enabling Specifications and Use Cases7.1.3. Helping Developers, Too7.1.4. Your Mileage may Vary7.2. Who is Going to Use Our Software?7.2.1. User Profiles7.2.2. Personas7.2.3. User Profiles or Personas?7.2.4. User Roles and Terminology7.3. What do the Users Want to Use Our Software for?7.3.1. Feature Lists7.3.2. Dataflow Diagrams7.3.3. Personas and Scenarios7.3.4. Narratives7.3.5. Behavior-Driven Development7.3.6. Now that We're Warmed Up ...7.3.6.1. Prototypes7.3.6.2. Towards Foundations for Decisions7.3.6.3. Known and Unknown Unknowns7.3.6.4. Use Cases as a Decision Framework7.4. Why Does the User Want to Use Our Software?7.5. Consolidation of What the System Does7.5.1. The Helicopter View7.5.1.1. Habits: The Developer View and the User View7.5.1.2. Trimming the Scope7.5.2. Setting the Stage7.5.3. Play the Sunny Day Scenario7.5.3.1. Business Rules7.5.4. Add the Interesting Stuff7.5.5. Use Cases to Roles7.5.5.1. Roles from the Use Case7.5.5.2. Bridging the Gap between the Business and the Programmer7.6. Recap7.6.1. Support the User's Workflow7.6.2. Support Testing Close to Development7.6.3. Support Efficient Decision-Making about Functionality7.6.4. Support Emerging Requirements7.6.5. Support Release Planning7.6.6. Support Sufficient Input to the Architecture7.6.7. Support the Team's Understanding of What to Develop7.7. "It Depends": When Use Cases are a Bad Fit7.7.1. Classic OO: Atomic Event Architectures7.8. Usability Testing7.9. Documentation?7.10. History and Such
8.1. The Big Picture: Model-View-Controller-User8.1.1. What is a Program?8.1.2. What is an Agile Program?8.1.3. MVC in More Detail8.1.4. MVC-U: Not the End of the Story8.1.4.1. A Short History of Computer Science8.1.4.2. Atomic Event Architectures8.1.4.3. DCI Architectures8.2. The Form and Architecture of Atomic Event Systems8.2.1. Domain Objects8.2.2. Object Roles, Interfaces, and the Model8.2.2.1. Example8.2.3. Reflection: Use Cases, Atomic Event Architectures, and Algorithms8.2.4. A Special Case: One-to-Many Mapping of Object Roles to Objects8.3. Updating the Domain Logic: Method Elaboration, Factoring, and Re-factoring8.3.1. Creating New Classes and Filling in Existing Function Placeholders8.3.1.1. Example8.3.2. Back to the Future: This is Just Good Old-Fashioned OO8.3.3. Analysis and Design Tools8.3.4. Factoring8.3.5. A Caution about Re-Factoring8.4. Documentation?8.5. Why All These Artifacts?8.6. History and Such
9.1. Sometimes, Smart Objects Just Aren't Enough9.2. DCI in a Nutshell9.3. Overview of DCI9.3.1. Parts of the User Mental Model We've Forgotten9.3.2. Enter Methodful Object Roles9.3.3. Tricks with Traits9.3.4. Context Classes: One Per Use Case9.4. DCI by Example9.4.1. The Inputs to the Design9.4.2. Use Cases to Algorithms9.4.3. Methodless Object Roles: The Framework for Identifiers9.4.4. Partitioning the Algorithms Across Methodful Object Roles9.4.4.1. Traits as a Building Block9.4.4.2. In Smalltalk9.4.4.3. In C++9.4.4.4. In Ruby9.4.4.5. Coding it Up: C++9.4.4.6. Coding Up DCI in Ruby9.4.5. The Context Framework9.4.5.1. The Ruby Code9.4.5.2. The C++ Code9.4.5.3. Making Contexts Work9.4.5.4. Habits: Nested Contexts in Methodful Object Roles9.4.6. Variants and Tricks in DCI9.4.6.1. Context Layering9.4.6.2. Information Hiding9.4.6.3. Selective Object Role Injection9.5. Updating the Domain Logic9.5.1. Contrasting DCI with the Atomic Event Style9.5.2. Special Considerations for Domain Logic in DCI9.6. Context Objects in the User Mental Model: Solution to an Age-Old Problem9.7. Why All These Artifacts?9.7.1. Why not Use Classes Instead of "Methodful Object Roles"?9.7.2. Why not Put the Entire Algorithm Inside of the Class with which it is Most Closely Coupled?9.7.3. Then Why not Localize the Algorithm to a Class and Tie it to Domain Objects as Needed?9.7.4. Why not Put the Algorithm into a Procedure, and Combine the Procedural Paradigm with the Object Paradigm in a Single Program?9.7.5. 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?'9.7.6. So, What do DCI and Lean Architecture Give Me?9.7.7. And Remember...9.8. Beyond C++: DCI in Other Languages9.8.1. Scala9.8.2. Python9.8.3. C#9.8.4. ...and Even Java9.8.5. The Account Example in Smalltalk9.9. Documentation?9.10. History and Such9.10.1. DCI and Aspect-Oriented Programming9.10.2. Other Approaches
F.1. Testing PerspectiveF.2. Data PerspectiveF.2.1. BB5BankF.2.2. BB5SavingsAccountF.2.3. BB5CheckingAccountF.3. Context PerspectiveF.3.1. BB5MoneyTransferContextF.4. Interaction (RoleTrait) PerspectiveF.4.1. BB5MoneyTransferContextTransferMoneySourceF.4.2. BB5MoneyTransferContextMyContextF.4.3. BB5MoneyTransferContextTransferMoneySinkF.5. Support Perspective (Infrastructure Classes)F.5.1. BB1Context (Common Superclass for all Contexts)F.5.2. BB1RoleTrait (All RoleTraits are Instances of this Class)

Overview

More and more Agile projects are seeking architectural roots as they struggle with complexity and scale - and they're seeking lightweight ways to do it

Still seeking? In this book the authors help you to find your own path
Taking cues from Lean development, they can help steer your project toward practices with longstanding track records
Up-front architecture? Sure. You can deliver an architecture as code that compiles and that concretely guides development without bogging it down in a mass of documents and guesses about the implementation
Documentation? Even a whiteboard diagram, or a CRC card, is documentation: the goal isn't to avoid documentation, but to document just the right things in just the right amount
Process? This all works within the frameworks of Scrum, XP, and other Agile approaches