Lean Architecture 1: Domain Architecture

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 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 natural foundation for Agile Feature Architecture.

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

  • The importance of "factoring" and "re-factoring"

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. Transformational Analysis

    5. Variability Tables

    6. Transformational Analysis

    7. Reducing to Code

    8. Domain Depedency graphs

• 7. The MVC-U Four-Layer Architecture

• • 1. Business Objects and Domain Modeling

    2. Business Objects as Tools

    3. Tools and MVC

• 8. Summary and wrapup