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
Table of contents
- Publisher's Acknowledgments
- About the Authors
- 1.1. The Touchstones: Lean and Agile
- 1.2. Lean Architecture and Agile Feature Development
- 1.3. Agile Production
- 1.4. The Book in a Very Small Nutshell
- 1.5. Lean and Agile: Contrasting and Complementary
- 1.6. Lost Practices
- 1.7. What this Book is Not About
- 1.8. Agile, Lean — Oh, Yeah, and Scrum and Methodologies and Such
- 1.9. History and Such
- 2. Agile Production in a Nutshell
3. Stakeholder Engagement
- 3.1. The Value Stream
3.2. The Key Stakeholders
- 3.2.1. End Users
- 3.2.2. The Business
- 3.2.3. Customers
- 3.2.4. Domain Experts
- 3.2.5. Developers and Testers
- 3.3. Process Elements of Stakeholder Engagement
- 3.4. The Network of Stakeholders: Trimming Wasted Time
- 3.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 Definitions
- 4.4. Problems and Solutions
- 4.5. The Process Around Problem Definitions
- 4.6. Problem Definitions, Goals, Charters, Visions, and Objectives
- 4.7. Documentation?
5. What the System Is, Part 1: Lean Architecture
5.1. Some Surprises about Architecture
- 5.1.1. What's Lean about This?
- 5.1.2. What's Agile about Architecture?
5.2. The First Design Step: Partitioning
- 5.2.1. The First Partition: Domain Form Versus Behavioral Form
- 5.2.2. The Second Partitioning: Conway's Law
- 5.2.3. The Real Complexity of Partitioning
- 5.2.4. Dimensions of Complexity
- 5.2.5. Domains: A Particularly Interesting Partitioning
- 5.2.6. Back to Dimensions of Complexity
- 5.2.7. Architecture and Culture
- 5.2.8. Wrap-Up on Conway's Law
5.3. The Second Design Step: Selecting a Design Style
- 5.3.1. Contrasting Structuring with Partitioning
- 5.3.2. The Fundamentals of Style: Commonality and Variation
- 5.3.3. Starting with Tacit Commonality and Variation
- 5.3.4. Commonality, Variation, and Scope
- 5.3.5. Making Commonalities and Variations Explicit
- 5.3.6. The Most Common Style: Object Orientation
- 5.3.7. Other Styles within the Von Neumann World
- 5.3.8. Domain-Specific Languages and Application Generators
- 5.3.9. Codified Forms: Pattern Languages
- 5.3.10. Third-Party Software and Other Paradigms
- 5.4. Documentation?
- 5.5. History and Such
- 5.1. Some Surprises about Architecture
6. What the System Is, Part 2: Coding It Up
6.1. The Third Step: The Rough Framing of the Code
- 6.1.1. Abstract Base Classes
- 6.1.2. Pre-Conditions, Post-Conditions, and Assertions
- 6.1.3. Algorithmic Scaling: The Other Side of Static Assertions
- 6.1.4. Form Versus Accessible Services
- 6.1.5. Scaffolding
- 6.1.6. Testing the Architecture
- 6.2. Relationships in Architecture
- 6.3. Not Your Old Professor's OO
- 6.4. How much Architecture?
- 6.5. Documentation?
- 6.6. History and Such
- 6.1. The Third Step: The Rough Framing of the Code
7. What the System Does: System Functionality
- 7.1. What the System Does
- 7.2. Who is Going to Use Our Software?
7.3. What do the Users Want to Use Our Software for?
- 7.3.1. Feature Lists
- 7.3.2. Dataflow Diagrams
- 7.3.3. Personas and Scenarios
- 7.3.4. Narratives
- 7.3.5. Behavior-Driven Development
- 7.3.6. Now that We're Warmed Up ...
- 7.4. Why Does the User Want to Use Our Software?
7.5. Consolidation of What the System Does
- 7.5.1. The Helicopter View
- 7.5.2. Setting the Stage
- 7.5.3. Play the Sunny Day Scenario
- 7.5.4. Add the Interesting Stuff
- 7.5.5. Use Cases to Roles
- 7.6.1. Support the User's Workflow
- 7.6.2. Support Testing Close to Development
- 7.6.3. Support Efficient Decision-Making about Functionality
- 7.6.4. Support Emerging Requirements
- 7.6.5. Support Release Planning
- 7.6.6. Support Sufficient Input to the Architecture
- 7.6.7. Support the Team's Understanding of What to Develop
- 7.7. "It Depends": When Use Cases are a Bad Fit
- 7.8. Usability Testing
- 7.9. Documentation?
- 7.10. History and Such
8. Coding It Up: Basic Assembly
- 8.1. The Big Picture: Model-View-Controller-User
- 8.2. The Form and Architecture of Atomic Event Systems
- 8.3. Updating the Domain Logic: Method Elaboration, Factoring, and Re-factoring
- 8.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 Enough
- 9.2. DCI in a Nutshell
- 9.3. Overview of DCI
9.4. DCI by Example
- 9.4.1. The Inputs to the Design
- 9.4.2. Use Cases to Algorithms
- 9.4.3. Methodless Object Roles: The Framework for Identifiers
- 9.4.4. Partitioning the Algorithms Across Methodful Object Roles
- 9.4.5. The Context Framework
- 9.4.6. Variants and Tricks in DCI
- 9.5. Updating the Domain Logic
- 9.6. Context Objects in the User Mental Model: Solution to an Age-Old Problem
9.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 Languages
- 9.9. Documentation?
- 9.10. History and Such
- 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 Perspective
- F.2. Data Perspective
- F.3. Context Perspective
- F.4. Interaction (RoleTrait) Perspective
- F.5. Support Perspective (Infrastructure Classes)
- Title: Lean Architecture for Agile Software Development
- Release date: August 2010
- Publisher(s): Wiley
- ISBN: 9780470684207
You might also like
Python Crash Course, 2nd Edition
This is the second edition of the best selling Python book in the world. Python Crash …
SAFe 4.5 Reference Guide: Scaled Agile Framework for Lean Enterprises, Second edition
The Must-have Reference Guide for SAFe® Professionals “There are a lot of methods of scale out …
Effective Computation in Physics
More physicists today are taking on the role of software developer as part of their research, …
"Does technology actually matter? And how can we apply technology to drive business value? For years, …