book

Lean Architecture for Agile Software Development

Name: Lean Architecture for Agile Software Development
ISBN: 9780470684207

by James Coplien, Gertrud Bjørnvig

August 2010

Intermediate to advanced

376 pages

10h 6m

English

Wiley

Read now

Unlock full access

Copyright
Publisher's Acknowledgments
About the Authors
Preface
1. Introduction
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. Agile Production in a Nutshell
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. Stakeholder Engagement
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. Problem Definition
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. What the System Is, Part 1: Lean Architecture
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. What the System Is, Part 2: Coding It Up
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. What the System Does: System Functionality
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. Coding It Up: Basic Assembly
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. Coding it Up: The DCI Architecture
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
10. Epilog
A. Scala Implementation of the DCI Account Example
B. Account Example in Python
C. Account Example in C#
D. Account Example in Ruby
E. Qi4j
F. Account Example in Squeak
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)
Bibliography

Content preview from Lean Architecture for Agile Software Development

Bibliography

(Adams et al 1998) Adams Michael, Coplien James, Gamoke Robert, Hanmer Robert, Keeve Fred, and Nicodemus Keith. Fault-tolerant telecommunication system patterns. In Linda Rising, ed., The Patterns Handbook: Techniques, Strategies, and gApplications. Cambridge University Press, January 1998, 189–202.

(Adolph et al 2002) Adolph, Steve, Bramble Paul, Cockburn Alistair, and Pols Andy. Patterns for effective use cases. Reading, MA: Addison-Wesley, 2002.

(Alexander 1974) Alexander, Christopher. Notes on the Synthesis of Form. Oxford University Press, paperback edition, 1974.

(Alexander 1979) Alexander, Christopher. The Timeless Way of Building. Oxford: Oxford University Press, 1979.

(Allen and Henn 2006) Allen, J. Thomas, and Henn Gunter. The organization and architecture of innovation: Managing the flow of technology. Oxford: Butterworth-Heinemann, 2006.

(Auer and Miller 2002) Auer, Ken, and Miller Roy. Extreme programming applied: playing to win. Pearson Education, 2002.

(Austin et al 1998) S. Austin, A. Baldwin, B. Li, and P. Waskett Analytical Design Planning Technique (ADePT): a dependency structure matrix tool to schedule the building design process. Construction Management and Economics, December 1999.

(Ballard 2000) Ballard Glenn. Positive vs. negative iteration in design. From URL www.leanconstruction.org/pdf/05.pdf, accessed 18 July 2008.

(Beck 1991) Beck Kent. Think like an object. In Unix Review, September 1991, ff. 41.

(Beck 1994) Beck Kent. Simple Smalltalk ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9780470684207Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Lean Architecture for Agile Software Development

by James Coplien, Gertrud Bjørnvig

Bibliography

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.