The Agile Manifesto and Lean both give us principles. If we translate those principles to concrete practices and techniques for software architecture, we find the following pieces of advice:
- Focus on the essence of the system form (what the
system is) without being unduly influenced by the functionality that the system
provides (what the system does).
- Focus on the form of what the system is,
partition it so that each part can be managed as autonomously as possible.
- The dominant consideration in supporting team
autonomy is how locally common changes are handled.
Let the human considerations drive the
partitioning, with software engineering concerns secondary.
attentive to domain partitioning. In particular, don’t split a domain across
geographic locations or across architectural units.
attentive to the opportunity to use product lines and use this insight to
bolster support for domain partitioning where possible.
- Allow the module partitioning to follow domain knowledge.
Think of domain knowledge as a timeless compression of the mental models of end
users and other stakeholders—mental models whose patterns are tacitly driven by
commonality and variation.
- In the absence of domain knowledge, allow the
module partitioning to follow the end user cognitive model of the domain. For
every user “notion” create a corresponding architectural notion.
- Capture your initial architecture at the most compressed level of expression
that covers the scope of your business. Avoid abstraction or the discarding of
any priceless information that may give insight on the form.
- In fact, the initial partitioning is to create decoupled businesses whose
concerns can be separated from each other.
- Most domains in simple, interactive applications
lead to modules that are implemented using object-based or object-oriented programming.
This is particularly true for entities that the program presents on an
interactive interface for direct manipulation by users.
- The object structures in the what-the-system-is
part of the architecture will become part of the Model in a
- Provide an API to the code generated from a DSL
for use by the rest of the architecture.
you have a trustworthy pattern language for your domain, use it instead of
domain analysis or end user input.
standards when dealing with third-party software.
- Factor changes to third-party software into local parameters of variation or
modules that are loosely coupled to the foreign software.
essence of “Lean” in Lean architecture is to take careful, well-considered
analysis and distill it into APIs written in everyday programming languages.