Why is a clean, simple, flexible, evolvable, and agile
architecture important?
Software architecture is the high level structure of a software system, the
discipline of creating such structures, and the documentation of these
structures. [1]
It is the set of structures needed to reason about the software system, and
comprises the software elements, the relations between them, and the
properties of both elements and relations. [2]
In today’s software development world, requirements change,
environments change, team members change, technologies change, and so
should the architecture of our systems.
The architecture defines the parts of a system that are hard and costly to
change. Therefore we are in need of a clean, simple, flexible, evolvable, and
agile architecture to be able to keep up with all the changes surrounding us.
Clean architecture [3]
An architecture that allows to replace details and is easy to verify.
Entities: Entities encapsulate enterprise-wide business rules. An entity can
be an object with methods, or it can be a set of data structures and
functions.
Use cases: Use cases orchestrate the flow of data to and from the entities,
and direct those entities to use their enterprise-wide business rules to
achieve the goals of the use cases.
Interface adapters: Adapters that convert data from the format most
convenient for the use cases and entities, to the format most convenient for
some external agency such as a database or the Web.
Frameworks and drivers: Glue code to connect UI, databases, devices etc.
to the inner circles.
Program Flow: Starts on the outside and ends on the outside, but can go
through several layers (user clicks a button, use case loads some entities
from DB, entities decide something that is presented on the UI)
Dependency management
The concentric circles represent different areas of software. In general, the
further in you go, the higher level the software becomes. The outer circles
are mechanisms. The inner circles are policies.
Source code dependencies can only point inwards. Nothing in an inner circle
can know anything at all about something in an outer circle. Use
dependency inversion to build up the system (classes in an outer circle
implement interfaces of an inner circle or listen to events from inner
circles).
Independent of frameworks
The architecture does not depend on the existence of some library of
feature-laden software. This allows you to use such frameworks as tools,
rather than having to cram your system into their technical constraints.
Testable
The business rules and use cases can be tested without UI, database, Web
server, or any other external element.
Independent of system boundaries (UI, database, …)
The UI, database, or any other external element can easily change without
any impact on use cases and business rules.
Simple architecture
An architecture that is easy to understand. Simplicity is, however,
subjective.
Consistent design decisions
One problem has one solution. Similar problems are solved similarly.
Number of concepts/technologies
Simple solutions make use of only a few different concepts and
technologies.
Number of interactions
The less interactions the simpler the design.
A reasonable amount of components with only efferent coupling and most
of the others with preferably only afferent coupling.
Size
Small systems/components are easier to grasp than big ones. Build large
systems out of small parts.
Modularity
Build your system by connecting independent modules with a clearly
defined interface (e.g. with adapters).
Flexible architecture
An architecture that supports change.
Separation of concerns
Divide your system into distinct features with as little overlap in
functionality as possible so that they can be combined freely.
Software reflects user’s mental model
When the structure and interactions inside the software match the user’s
mental model, changes in the real world can more easily be applied in
software.
Abstraction
Separating ideas from specific implementations provides the flexibility to
change the implementation. But beware of `over abstraction`.
Interface slimness
Fat interfaces between components lead to strong coupling. Design the
interfaces to be as slim as possible. But beware of `ambiguous interfaces`.
Prefer composition over inheritance
Inheritance increases coupling between parent and child, thereby limiting
reuse.
Tangle-/cycle-free dependencies
The dependency graph of the elements of the architecture has no cycles,
thus allowing locally bounded changes.
Evolvable architecture
An architecture that is easy to adapt step by step to keep up with changes.
Matches current needs, not the future
The architecture of the current system should match the current needs
(functional and non-functional) – not some future ones. This results in
simpler, easier to understand solutions. Otherwise, the risk of waste is very
high.
No dead-ends, architecture can be extended/adapted
The current architecture should be extendable and adaptable so that future
needs can be addressed. When evaluating different alternatives, choose
one that is open for change.
Architecture agnostic components
When components don’t care about which architecture they run in, the
architecture can be changed without having to rewrite the components.
Sacrificial architecture [4]
When the software has outlived its architecture, throw the architecture
away and start over. This mindset can be used to build a first version with a
very simple architecture, then start over for the next.
Rolling refactoring [5]
When a new version of a concept is introduced, then the old one is
refactored out step by step. There can be at most two versions of a concept
in an application (and it should be temporary).
Agile architecture
An architecture that supports agile software development by enabling the
principles of the Agile Manifesto [6].
Allow change quickly
The architecture allows quick changes through flexibility and evolvability.
Verifiable at any time
The architecture can be verified (fulfils all quality aspects) at any time (e.g.
every Sprint).
Rapid deployment
The architecture supports continuous and rapid deployment so that
stakeholders can give feedback continuously.
Always working
The system is always working (probably with limited functionality) so that it
is potentially shippable any time/at end of Sprint. Use assumptions,
simplifications, simulators, shortcuts, hard-coding to build a walking
skeleton.
Workflow
Use a top-down approach to find the architecture.
1. Context
What belongs to your system and what does not? Which external services
will you use?
2. Break down into parts
Split the whole into parts by applying separation of concerns and the single-
responsibility principle.
3. Communication
Which data flows through which call, message or event from one part to
another? What are the properties of the channels (sync/async, reliability, …)
4. Repeat for each part
Repeat the above-mentioned three steps for each part as if it were your
system.
A part is a bounded context, subsystem or component.
Defer decisions
Decide only things you have enough knowledge about. Otherwise find a way
to defer the decision and build up more knowledge. A good architecture
allows you to defer most decisions.
Abstraction
Use an abstraction to hide details so that you don’t have to decide about
the details, but can use a simulation/fake at first to build up more
knowledge.
Simplification
Simplify the problem so that a decision can be made and work can progress.
Use this to break free from a blocking state, but be aware of the risks a
wrong decision could have.
Wilful ignorance
Refuse to decide and wait until more knowledge about the problem and its
potential solutions is built up.
Decision delegation
Build the (part of a) system in a way that doesn’t require any decision, by
making some other (part of the) system responsible that can be
implemented later. E.g. instead of deciding how to persist data, make the
code calling your code responsible for passing all needed data to your code.
This allows you to build your whole business logic and decide about
persistence when implementing the host that runs the business logic.
Architecture influencing forces
Quality attributes
The needed quality attributes (functionality, reliability, usability, efficiency,
maintainability, portability, …) are the primary drivers for architectural
decisions.
Team know-how and skills
The whole team understands and supports architecture and can make
design decisions according to the architecture.
Easiness of implementation
How easy an envisioned architecture can be implemented is a quality
attribute.
Cost of operations
Most costs of a software system accrue during operations, not
implementation.
Risks
Every technology, library, and design decision has its risks.
Inherent opportunities
Things the architecture would allow us to do (but without investing any
additional effort because we may never need it).
Technology churn
Availability of new (better) technologies, resulting in a need for architecture
change.
Trade-offs
Designing an architecture comprises making trade-offs between conflicting
goals. Trade-offs must reflect the priorities of quality attributes set by the
stakeholders. Trade-offs should be documented and communicated to all
stakeholders.
Architecture degrading forces
Architectural drift
Introduction of design decisions into a system’s actual architecture that are
not included in, encompassed by, or implied by the planned architecture.
Architectural erosion
Introduction of design decisions into a system’s actual architecture that
violate its planned architecture.
Architecture killers
Split brain
Different parts of the system claim ownership of the same data or their
interpretation resulting in inconsistencies and difficult synchronisation.
Coupling in space and time
E.g. shared code to remove duplication hinders independent advancements,
a service that needs other services to be up and running, an `initialise`
method that has to be called prior to any other method on the class (better
use constructor injection or a factory).
Dead-end
A design decision that prevents further adaptability without a major
refactoring or rewrite.
Direction of
Dependencies
Use Cases
Interface Adapters
Frameworks & Drivers
Entities
UI
External
Interfaces
DB
Web
Program Flow
time
knowledge
learn
decide
enrich
Clean simple flexible evolvable agile Architecture
