Gertrud Bjørnvig & James O. Coplien 
Lean Architecture 
for Agile Software Development

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

İçerik tablosu

About the Authors.

Preface.

1 Introduction.

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.

4.7 Documentation?

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.4 Documentation?

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.5 Documentation?

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.6 Recap.

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.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.9 Documentation?

9.10 History and Such.

10 Epilog.

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 (Role Trait) Perspective.

F.5 Support Perspective (Infrastructure Classes).

Bibliography.

Index.

Yazar hakkında

James O. Coplien is a writer, lecturer, and researcher in
the field of Computer Science. He has made key contributions in the
areas of software design and organizational development, software
debugging, and in empirical research. His early work on C++ idioms
was one of the three primary sources of the popular Design
Patterns. His work on Organizational patterns was an inspiration
for both Extreme Programming and for Scrum. Cope was a founding
Member of Hillside Group with Kent Beck, Grady Booch, Ward
Cunningham, Ralph Johnson, Ken Auer and Hal Hildebrand. He is
responsible for starting up several of the conferences in the
Pattern Languages of Programming (PLo P) conference series and is a
longstanding pattern author and PLo P shepherd.

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
Tieto Enator, 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.