Lean Architecture: Form and Function

Agile Architecture is not Fragile Architecture!

There is a popular misconception that Agile development means not doing architecture, yet every major school of Agile practice advocates architecture. You can do a great Agile architecture in one week or in a single sprint, and overwhelming industry experience with Scrum bears out a return on investment before the end of your third sprint! In this course, designed as a one-day addendum to the Scrum course, we'll teach you how great projects do architecture the Agile way.

The first part of architecture is the form of what the system is. By focusing on form and delivering the architecture as code, instead of through a wasteful intermediate notation, a project can increase its velocity and prepare itself for just-in-time delivery. Features can be delivered faster by applying Lean principles.

The second part of architecture is the form of what the system does. This architecture several important end-user mental models. Architecture usually captures the end user's domain model, as we did above in "what the system is." Beyond that are four more mental models: the roles taken on by those domain objects; the mapping from those roles to the objects they wrap; the collaboration structure between the roles; and the algorithm encapsulated in the roles.

The course focuses in interactive systems and draws from a broad range of sources including Trygve Reenskaug's work on architectural underpinnings of MVC and his new work on the DCI architecture, Jim Coplien's lightweight domain analysis, dressed-down Use Cases, CRC cards, and role-basesd development. The course is for architects, designers, and programmers, and is programming-language neutral. This course is a compressed overview of Lean Architecture and Implementing Agile Requirements.

Target audience:

• • Designers;

  • Programmers;

  • System and software architects;

  • White-box /clear-box testers;

  • Line managers;

  • User experience folks (there is an important and surprising relationship between HCI and architecture in an Agile system);

  • Domain experts;

  • System Engineers;

  • To a lesser degree, ScrumMasters and Product Owners (wouldn't it be nice to know where architectural PBIs come from and where they go?)

Prerequisites:

• • Familiarity with Agile vocabulary;

  • At least two years of professional experience in some domain;

  • Competence in a modern mainstream programming language (Java, C#, or C++)

You'll learn:

• • Why architecture is perhaps more crucial to Agile development than to conventional development;

  • How to adapt Agile techniques so that they are supported by a good architecture, rather than doing damage to the architecture

  • How to sustain a business object architecture and domain object architecture that support each other

  • An overall development framework that reduces cost and has prospects for increasing revenues

  • How to reduce risk with eager decision-making strategies

  • Trygve Reenskaug's new framework for capturing requirements in code: Data, Context and Interaction (DCI)

  • Why User Stories are not enough, and what you need to understand the important relationships between requirements

  • How to implement two different kinds of architecture for two different kinds of end user interaction: atomic interactions, and sequences of tasks in context

  • How to reduce documentation needs by increasing code intentionality

  • How to package Use Case requirements into code that is as readable as the Use Case, instead of being spread across system classes

Outline

• 1. Introduction

  2. Time and Time to Market: Motivating Architecture's Value

     1. YAGNI Re-visited

     2. Case studies and models of profitability with and without up-front work

  3. Architecture and Technique

• • 1. The Potential for TDD to erode architecture — and the remedy

    2. Symbiosis between architecture and usability: MVC foundations and business objects

    3. The link from architecture to functional requirements and Use Cases

• 4. Architecture and Maintainability

• • 1. Lightweight Domain Modeling

    2. How much architecture?

    3. Software Families

    4. Commonality and Variability Analysis

• 5. Domain-Driven Design: Problem Domain Analysis

• • 1. Commonality and Variation

    2. Domain Starter Sets

• 6. Solution Domain Analysis

• • 1. The Paradigms

    2. Positive and Negative Variation

    3. Simple Domain Parititioning

    4. Variability Tables

    5. Transformational Analysis

    6. Reducing to Code

• 7. The MVC-U Four-Layer Architecture

• • 1. Business Objects and Domain Modeling

    2. Business Objects as Tools

    3. Tools and MVC

• 8. Architecture in Process

• • 1. Incremental Architectural Slices

    2. How much architecture, and when?

• 9. Capturing functionality in Code: Trygve Reenskaug's DCI architecture

• • 1. Code intentionality

    2. A model from the perspective of Aspects

    3. Class and object definitions of weavers

    4. Role definitions

    5. Capturing Use Cases

    6. Methodful roles

    7. Tieing it all together

• 10. Summary and Wrapup