1.
Introduction and deep dive into
the idea of Software Architecture
Matt Clarke - Genesis Energy - Sep 2018

2.
What we’ll (aim to) cover
• Grounding for the idea of software architecture
• What is it and does it really matter?
• Boundaries, Abstractions and Layers
• Package by layer vs. package by feature
• Brief overview of Clean Architecture
• The Dependency Rule
• How and why software architecture can go wrong
• Parallels with Agile
• Skin in the Game and the role of Architects

3.
What is Software
Architecture?

4.
What is a part of the
Software Architecture?
• Choice of programming language?
• Choice of UI framework?
• REST vs. GraphQL?
• Choice of logging, analytics or monitoring tool?
• Authentication & authorization library?
• Web vs. mobile vs. terminal front-end?

5.
• These things are important…
• But they’re of secondary importance to
the software’s architecture
• They’re still details, relatively speaking
• They are not (or should not) be
architectural/foundational to your
software

6.
What is software
architecture?

7.
What is software
architecture?
• Why does this distinction matter? Why bother
thinking about your software in this way? What
makes you think this is more important than choice
of UI framework or database?
• Why does the structure of your project at the
highest level matter?

8.
What does a badly-
architected project look
like?

9.
What does a badly
architected project look like?
• Spaghetti code
• No clear boundaries (or ‘rooms’)
• Everything knows about everything else
• Hard to find what you’re looking for
• Chaotic - difficult to see patterns or logic
• Difficult to test - parts or the whole system

10.
But why are any of these
things necessarily bad?

11.
Why is an unstructured, chaotic,
unclear project actually bad?
• Let’s begin by assuming it would be a good thing for the world if your
software was useful to your customer
• From this it follows that your software becoming increasingly useless
over time would be a bad thing
• Unstructured, tangled code makes it difficult to keep the software
matching the customer’s needs over time
• If this trend continues, customers stop paying for your product
• Eventually, your project will be “sunset” or company will go bankrupt
• I.e. badly architected code is unsustainable

12.
The world is changing
• “The world is changing which means your business needs to
change, which means your software needs to change” - Marcus
Biel
• James McGill: “competitors, regulations, technology and
customer appetites are changing”
• Product/Market fit is a function of both product and market
• If the market is moving (and it always is) and your product isn’t,
it’s getting worse
• Another key point: market changes are largely unpredictable
due to the reality of limited information

13.
"Now, here, you see, it takes all the running you can do, to keep in the
same place. If you want to get somewhere else, you must run at least
twice as fast as that!"

14.
Code rot
• The situation where code is too difficult/complex to
change to keep up with demands is sometimes
known as code rot
• When a project or business fails due to technical
reasons, it’s usually due to code rot
• I.e. unmanageable complexity

15.
“Projects fail most often because
of poor requirements, poor
planning, or poor management.
But when projects do fail for
reasons that are primarily
technical, the reason is often
uncontrolled complexity. The
software is allowed to grow so
complex that no one really
knows what it does.”

16.
Does Software Architecture
matter?
• At the very least, we’ve established that having a
bad architecture matters, in the negative sense
• Uncontrolled complexity = eventual project failure
• Implication: getting away from bad/no architecture
matters
• What would characterise a “good architecture”
then?

17.
Well-designed architecture?
• Is a tool for humans to keep software complexity
manageable…
• …so that we can easily and safely change it to
keep up with the environment

18.
Well-designed architecture?
• A good architecture optimises the source code for
humans to “live in” (read: understand and freely
change)
• Particularly: a good software architecture is
optimised for the fact that human processing
speed and working memory is very limited
(relative to a machine)
• Code complexity is a problem for humans, not
machines (relatively speaking)

19.
The Humble Programmer -
Edsger W. Dijkstra (1972)
• “We shall do a much better programming job,
provided that we approach the task with a full
appreciation of its tremendous difficulty, provided
that we stick to modest and elegant programming
languages, provided that we respect the intrinsic
limitations of the human mind and approach the
task as Very Humble Programmers.”

20.
Well-designed architecture?
• A good architecture lets you step into an area of
the system to make a needed change, safely
ignoring everything outside for a while
• Like entering a room in a house
• Ideally, everything you need is at hand. You don’t
need to search each room of the house for the
ingredients to cook dinner
• How can this be achieved?

21.
Boundaries
• Boundaries are a tool for holding back complexity/
chaos
• They simplify the world by limiting the number of
things that need to be considered at once
• A software architecture could be described as the
choice of boundaries and connections between
bounded areas (dependencies)

22.
Boundaries
• Bounded components are also a form of redundancy
• Redundancy limits the impact caused by unexpected
changes in requirements
• Impact of changes can be contained to a few
components rather than affecting the entire system
(full regression!)
• Redundancy makes the software more robust to
future changes

23.
Types of software
boundaries
• Function
• Class
• Interface
• Package/directory
• Module
• Library
• Process on the same machine
• Process on another machine (API boundary)

24.
Boundary <-> abstraction
• Boundaries in software are represented by abstractions
• Abstraction: “The act of abstracting, separating,
withdrawing, or taking away; withdrawal; the state of
being taken away.”
• The essence of abstractions is preserving information that
is relevant in a given context, and forgetting information
that is irrelevant in that context. – John V. Guttag
• Abstractions hide irrelevant details, reducing complexity,
temporarily simplifying the world

25.
Boundary <-> abstraction

26.
Boundary <-> abstraction
public interface MusicPlayer {
void play();
void pause();
void stop();
void next();
void previous();
}

27.
Choice of boundaries
• So boundaries/abstractions are a good tool we can use to limit
complexity
• Does this mean we just need to add lots of boundaries to our
code to make it easier to understand?
• Drawing boundaries around something defines a category - it
groups things together based on them being similar in some way
• There’s a (near?) infinite number of ways you could groups
things
• Given that, how should you group code together optimally? How
do you choose where to draw boundaries?

28.
Well-designed architecture?
• A good architecture lets you step into an area of
the system to make a needed change, safely
ignoring everything outside for a while
• Like entering a room in a house
• Ideally, everything you need is at hand. You
don’t need to search each room of the house for
the ingredients to cook dinner

29.
Well-designed architecture?
• A choice of rooms that reduces the amount of room
changes (read: context switches) while going
about daily life would be make life easier
• Also the number of purposes for the room should
be limited, to limit effectively limit complexity

30.
Well-designed architecture?
• If a good architecture optimises the source code for
humans to “live in” (understand and freely change)…
• And the point of changes is to make the software more
useful to the customer in some way…
• Then it makes sense to group together code that
typically changes for the same reasons, or needs
changing at the same time
• This way when you find the right room (component/
module…), you have everything at hand to make the
desired business change

31.
Layered Architecture
• What are some classes of changes that commonly
occur at the same time?
• 3 tier architecture:
Presentation/UI
Domain/Business
Data

32.
Layered Architecture
• Here’s another valid way you could slice up code:
by feature (or use case)
Presentation/UI
Domain/Business
Data
Login Elec. Gas LPG Bills

33.
Layered Architecture
• Cross-cutting concerns: affect (at minimum) all
vertical slices. Possibly all parts of the app.
Presentation/UI
Domain/Business
Data
Login Elec. Gas LPG Bills
Logging,
analytics,
monitoring…

34.
Layered Architecture
Presentation/UI
Domain/Business
Data
Login Elec. Gas LPG Bills presentation/
login/
electricity/
gas/
domain/
login/
electricity/
gas/
data/
login/
electricity/
gas/

35.
Layered Architecture
Presentation/UI
Domain/Business
Data
Login Elec. Gas LPG Bills login/
presentation/
domain/
data/
electricity/
presentation/
domain/
data/
gas/
presentation/
domain/
data/

36.
The Dependency Rule
• Low-level details depend on high-level policy
• High-level business logic depends on abstractions
• These abstractions are depended on and implemented by
concrete, low-level details
• “ In general, the further in you go, the higher level the software
becomes. The outer circles are mechanisms. The inner circles are
policies.
The overriding rule that makes this architecture work is The
Dependency Rule. This rule says that source code dependencies
can only point inwards. Nothing in an inner circle can know
anything at all about something in an outer circle.”

37.
Agile Parallel
• Dependency Rule -> the Clean Architecture
• Agile principles -> Scrum

38.
Questions/discussion