Lean Architecture for Agile Software Development

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.

• 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