Lean Architecture – for Agile Software Development

About the Authors.
<p>Preface.</p>
<p>1 Introduction.</p>
<p>1.1 The Touchstones: Lean and Agile.</p>
<p>1.2 Lean Architecture and Agile Feature Development.</p>
<p>1.3 Agile Production.</p>
<p>1.4 The Book in a Very Small Nutshell.</p>
<p>1.5 Lean and Agile: Contrasting and Complementary.</p>
<p>1.6 Lost Practices.</p>
<p>1.7 What this Book is Not About.</p>
<p>1.8 Agile, Lean ? Oh, Yeah, and Scrum and Methodologies and Such.</p>
<p>1.9 History and Such.</p>
<p>2 Agile Production in a Nutshell.</p>
<p>2.1 Engage the Stakeholders.</p>
<p>2.2 Define the Problem.</p>
<p>2.3 Focusing on What the System Is: The Foundations of Form.</p>
<p>2.4 Focusing on What the System Does: The System Lifeblood.</p>
<p>2.5 Design and Code.</p>
<p>2.6 Countdown: 3, 2, 1. . . .</p>
<p>3 Stakeholder Engagement.</p>
<p>3.1 The Value Stream.</p>
<p>3.2 The Key Stakeholders.</p>
<p>3.3 Process Elements of Stakeholder Engagement.</p>
<p>3.4 The Network of Stakeholders: Trimming Wasted Time.</p>
<p>3.5 No Quick Fixes, but Some Hope.</p>
<p>4 Problem Definition.</p>
<p>4.1 What′s Agile about Problem Definitions?</p>
<p>4.2 What′s Lean about Problem Definitions?</p>
<p>4.3 Good and Bad Problem Definitions.</p>
<p>4.4 Problems and Solutions.</p>
<p>4.5 The Process Around Problem Definitions.</p>
<p>4.6 Problem Definitions, Goals, Charters, Visions, and Objectives.</p>
<p>4.7 Documentation?</p>
<p>5 What the System Is, Part 1: Lean Architecture.</p>
<p>5.1 Some Surprises about Architecture.</p>
<p>5.2 The First Design Step: Partitioning.</p>
<p>5.3 The Second Design Step: Selecting a Design Style.</p>
<p>5.4 Documentation?</p>
<p>5.5 History and Such.</p>
<p>6 What the System Is, Part 2: Coding It Up.</p>
<p>6.1 The Third Step: The Rough Framing of the Code.</p>
<p>6.2 Relationships in Architecture.</p>
<p>6.3 Not Your Old Professor′s OO.</p>
<p>6.4 How much Architecture?</p>
<p>6.5 Documentation?</p>
<p>6.6 History and Such.</p>
<p>7 What the System Does: System Functionality.</p>
<p>7.1 What the System Does.</p>
<p>7.2 Who is Going to Use Our Software?</p>
<p>7.3 What do the Users Want to Use Our Software for?</p>
<p>7.4 Why Does the User Want to Use Our Software?</p>
<p>7.5 Consolidation of What the System Does.</p>
<p>7.6 Recap.</p>
<p>7.7 "It Depends": When Use Cases are a Bad Fit.</p>
<p>7.8 Usability Testing.</p>
<p>7.9 Documentation?</p>
<p>7.10 History and Such.</p>
<p>8 Coding It Up: Basic Assembly.</p>
<p>8.1 The Big Picture: Model–View–Controller–User.</p>
<p>8.2 The Form and Architecture of Atomic Event Systems.</p>
<p>8.3 Updating the Domain Logic: Method Elaboration, Factoring, and Re–factoring.</p>
<p>8.4 Documentation?</p>
<p>8.5 Why All These Artifacts?</p>
<p>8.6 History and Such.</p>
<p>9 Coding it Up: The DCI Architecture.</p>
<p>9.1 Sometimes, Smart Objects Just Aren?t Enough.</p>
<p>9.2 DCI in a Nutshell.</p>
<p>9.3 Overview of DCI.</p>
<p>9.4 DCI by Example.</p>
<p>9.5 Updating the Domain Logic.</p>
<p>9.6 Context Objects in the User Mental Model: Solution to an Age–Old Problem.</p>
<p>9.7 Why All These Artifacts?</p>
<p>9.8 Beyond C++: DCI in Other Languages.</p>
<p>9.9 Documentation?</p>
<p>9.10 History and Such.</p>
<p>10 Epilog.</p>
<p>Appendix A Scala Implementation of the DCI Account Example.</p>
<p>Appendix B Account Example in Python.</p>
<p>Appendix C Account Example in C#.</p>
<p>Appendix D Account Example in Ruby.</p>
<p>Appendix E Qi4j.</p>
<p>Appendix F Account Example in Squeak.</p>
<p>F.1 Testing Perspective.</p>
<p>F.2 Data Perspective.</p>
<p>F.3 Context Perspective.</p>
<p>F.4 Interaction (RoleTrait) Perspective.</p>
<p>F.5 Support Perspective (Infrastructure Classes).</p>
<p>Bibliography.</p>
<p>Index.</p>