Aiming at no less than a paradigm shift, Lean Architecture uses a modern approach to software design, while embracing refreshing new insights of Lean and Agile. Giving a down–to–earth view of Agile requirements and the often–ignored relationship between requirements and architecture, this book goes beyond the fashionable idea of User Stories, and shows you how to employ Use Cases in a lightweight, incremental, Agile way. The authors detail the DCI (Data, Context and Interaction) architecture paradigm and show how DCI succeeds where object–oriented programming languages alone have failed to integrate software design with the end user′s understanding of the overall business structure.
However, this is not a methodology book, but a book which focuses on code, with plenty of code examples. Topics covered include: Agile production, Stakeholder Engagement, Organizational issues, Scala/Python/Java implementation of the DCI account example, Qi4J and much more.
Renowned software architecture expert James Coplien and agile requirements expert Gertrud Bjørnvig share their expertise to give you concrete design advice that will help you:
- Create software that builds on your end–user mental models rather than design methodologies
- Write software that can directly be verified against behavioral requirements
- Organize – so that all your stakeholders support each other
- Support rapidly changing feature code in stable domain code to help embrace change
Lean Architecture casts a new light over important aspects of software development that have been marginalized or forgotten by the agile movement it will help you find your own path.
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.
2.1 Engage the Stakeholders.
2.2 Define the Problem.
2.3 Focusing on What the System Is: The Foundations of Form.
2.4 Focusing on What the System Does: The System Lifeblood.
2.5 Design and Code.
2.6 Countdown: 3, 2, 1. . . .
3 Stakeholder Engagement.
3.1 The Value Stream.
3.2 The Key Stakeholders.
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.
5 What the System Is, Part 1: Lean Architecture.
5.1 Some Surprises about Architecture.
5.2 The First Design Step: Partitioning.
5.3 The Second Design Step: Selecting a Design Style.
5.5 History and Such.
6 What the System Is, Part 2: Coding It Up.
6.1 The Third Step: The Rough Framing of the Code.
6.2 Relationships in Architecture.
6.3 Not Your Old Professor′s OO.
6.4 How much Architecture?
6.6 History and Such.
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.4 Why Does the User Want to Use Our Software?
7.5 Consolidation of What the System Does.
7.7 "It Depends": When Use Cases are a Bad Fit.
7.8 Usability Testing.
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.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.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.8 Beyond C++: DCI in Other Languages.
9.10 History and Such.
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.
F.1 Testing Perspective.
F.2 Data Perspective.
F.3 Context Perspective.
F.4 Interaction (RoleTrait) Perspective.
F.5 Support Perspective (Infrastructure Classes).
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.