SlideShare a Scribd company logo
1 of 47
Download to read offline
Introduction and deep dive into
the idea of Software Architecture
Matt Clarke - Genesis Energy - Sep 2018
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
What is Software
Architecture?
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?
• 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
What is software
architecture?
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?
What does a badly-
architected project look
like?
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
But why are any of these
things necessarily bad?
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
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
"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!"
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
“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.”
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?
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
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)
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.”
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?
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)
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
Types of software
boundaries
• Function
• Class
• Interface
• Package/directory
• Module
• Library
• Process on the same machine
• Process on another machine (API boundary)
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
Boundary <-> abstraction
Boundary <-> abstraction
public interface MusicPlayer {
void play();
void pause();
void stop();
void next();
void previous();
}
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?
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
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
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
Layered Architecture
• What are some classes of changes that commonly
occur at the same time?
• 3 tier architecture:
Presentation/UI
Domain/Business
Data
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
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…
Layered Architecture
Presentation/UI
Domain/Business
Data
Login Elec. Gas LPG Bills presentation/

login/

electricity/

gas/

domain/

login/

electricity/

gas/

data/

login/

electricity/

gas/
Layered Architecture
Presentation/UI
Domain/Business
Data
Login Elec. Gas LPG Bills login/

presentation/

domain/

data/

electricity/

presentation/

domain/

data/

gas/

presentation/

domain/

data/
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.”
Agile Parallel
• Dependency Rule -> the Clean Architecture
• Agile principles -> Scrum
Questions/discussion

More Related Content

What's hot

Evolving toward Microservices - O’Reilly SACON Keynote
Evolving toward Microservices  - O’Reilly SACON KeynoteEvolving toward Microservices  - O’Reilly SACON Keynote
Evolving toward Microservices - O’Reilly SACON KeynoteChristopher Grant
 
Democratising Software Architecture
Democratising Software ArchitectureDemocratising Software Architecture
Democratising Software ArchitectureEoin Woods
 
Architecting Applications the Microsoft Way
Architecting Applications the Microsoft WayArchitecting Applications the Microsoft Way
Architecting Applications the Microsoft WayClint Edmonson
 
Models, Sketches and Everything In Between
Models, Sketches and Everything In BetweenModels, Sketches and Everything In Between
Models, Sketches and Everything In BetweenEoin Woods
 
Monolith to Microservices - O’Reilly Oscon
Monolith to Microservices - O’Reilly OsconMonolith to Microservices - O’Reilly Oscon
Monolith to Microservices - O’Reilly OsconChristopher Grant
 
Is your code SOLID enough?
 Is your code SOLID enough? Is your code SOLID enough?
Is your code SOLID enough?SARCCOM
 
A Software Architect's View On Diagramming
A Software Architect's View On DiagrammingA Software Architect's View On Diagramming
A Software Architect's View On Diagrammingmeghantaylor
 

What's hot (7)

Evolving toward Microservices - O’Reilly SACON Keynote
Evolving toward Microservices  - O’Reilly SACON KeynoteEvolving toward Microservices  - O’Reilly SACON Keynote
Evolving toward Microservices - O’Reilly SACON Keynote
 
Democratising Software Architecture
Democratising Software ArchitectureDemocratising Software Architecture
Democratising Software Architecture
 
Architecting Applications the Microsoft Way
Architecting Applications the Microsoft WayArchitecting Applications the Microsoft Way
Architecting Applications the Microsoft Way
 
Models, Sketches and Everything In Between
Models, Sketches and Everything In BetweenModels, Sketches and Everything In Between
Models, Sketches and Everything In Between
 
Monolith to Microservices - O’Reilly Oscon
Monolith to Microservices - O’Reilly OsconMonolith to Microservices - O’Reilly Oscon
Monolith to Microservices - O’Reilly Oscon
 
Is your code SOLID enough?
 Is your code SOLID enough? Is your code SOLID enough?
Is your code SOLID enough?
 
A Software Architect's View On Diagramming
A Software Architect's View On DiagrammingA Software Architect's View On Diagramming
A Software Architect's View On Diagramming
 

Similar to Deep Dive into the Idea of Software Architecture

Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyComsysto Reply GmbH
 
Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyComsysto Reply GmbH
 
ASAS 2014 - Simon Brown
ASAS 2014 - Simon BrownASAS 2014 - Simon Brown
ASAS 2014 - Simon BrownAvisi B.V.
 
No Silver Bullet - Essence and Accidents of Software Engineering
No Silver Bullet - Essence and Accidents of Software EngineeringNo Silver Bullet - Essence and Accidents of Software Engineering
No Silver Bullet - Essence and Accidents of Software EngineeringAditi Abhang
 
Model-driven and low-code development for event-based systems | Bobby Calderw...
Model-driven and low-code development for event-based systems | Bobby Calderw...Model-driven and low-code development for event-based systems | Bobby Calderw...
Model-driven and low-code development for event-based systems | Bobby Calderw...HostedbyConfluent
 
Software Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuableSoftware Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuableComsysto Reply GmbH
 
Agile Architecture (MAE slides)
Agile Architecture (MAE slides)Agile Architecture (MAE slides)
Agile Architecture (MAE slides)Richard Green
 
MWLUG 2015 - An Introduction to MVC
MWLUG 2015 - An Introduction to MVCMWLUG 2015 - An Introduction to MVC
MWLUG 2015 - An Introduction to MVCUlrich Krause
 
Domain Driven Design Big Picture Strategic Patterns
Domain Driven Design Big Picture Strategic PatternsDomain Driven Design Big Picture Strategic Patterns
Domain Driven Design Big Picture Strategic PatternsMark Windholtz
 
Chap 6 - Software Architecture Part 1.ppt
Chap 6 - Software Architecture Part 1.pptChap 6 - Software Architecture Part 1.ppt
Chap 6 - Software Architecture Part 1.pptkhalidnawaz39
 
Chap 6 - Software Architecture Part 1.pptx
Chap 6 - Software Architecture Part 1.pptxChap 6 - Software Architecture Part 1.pptx
Chap 6 - Software Architecture Part 1.pptxssuser0ed5b4
 
Software cracking and patching
Software cracking and patchingSoftware cracking and patching
Software cracking and patchingMayank Gavri
 
An Introduction To Model  View  Controller In XPages
An Introduction To Model  View  Controller In XPagesAn Introduction To Model  View  Controller In XPages
An Introduction To Model  View  Controller In XPagesUlrich Krause
 
2019-Nov: Domain Driven Design (DDD) and when not to use it
2019-Nov: Domain Driven Design (DDD) and when not to use it2019-Nov: Domain Driven Design (DDD) and when not to use it
2019-Nov: Domain Driven Design (DDD) and when not to use itMark Windholtz
 
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...Designing and Implementing Information Systems with Event Modeling, Bobby Cal...
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...confluent
 
Software Engineering (Introduction to Software Engineering)
Software Engineering (Introduction to Software Engineering)Software Engineering (Introduction to Software Engineering)
Software Engineering (Introduction to Software Engineering)ShudipPal
 
Technical stories v1.2
Technical stories v1.2Technical stories v1.2
Technical stories v1.2Jim Brisson
 
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...confluent
 

Similar to Deep Dive into the Idea of Software Architecture (20)

Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and Consistently
 
Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and Consistently
 
ASAS 2014 - Simon Brown
ASAS 2014 - Simon BrownASAS 2014 - Simon Brown
ASAS 2014 - Simon Brown
 
No silver bullet
No silver bulletNo silver bullet
No silver bullet
 
No Silver Bullet - Essence and Accidents of Software Engineering
No Silver Bullet - Essence and Accidents of Software EngineeringNo Silver Bullet - Essence and Accidents of Software Engineering
No Silver Bullet - Essence and Accidents of Software Engineering
 
Model-driven and low-code development for event-based systems | Bobby Calderw...
Model-driven and low-code development for event-based systems | Bobby Calderw...Model-driven and low-code development for event-based systems | Bobby Calderw...
Model-driven and low-code development for event-based systems | Bobby Calderw...
 
Software Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuableSoftware Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuable
 
OOSE UNIT-1.pdf
OOSE UNIT-1.pdfOOSE UNIT-1.pdf
OOSE UNIT-1.pdf
 
Agile Architecture (MAE slides)
Agile Architecture (MAE slides)Agile Architecture (MAE slides)
Agile Architecture (MAE slides)
 
MWLUG 2015 - An Introduction to MVC
MWLUG 2015 - An Introduction to MVCMWLUG 2015 - An Introduction to MVC
MWLUG 2015 - An Introduction to MVC
 
Domain Driven Design Big Picture Strategic Patterns
Domain Driven Design Big Picture Strategic PatternsDomain Driven Design Big Picture Strategic Patterns
Domain Driven Design Big Picture Strategic Patterns
 
Chap 6 - Software Architecture Part 1.ppt
Chap 6 - Software Architecture Part 1.pptChap 6 - Software Architecture Part 1.ppt
Chap 6 - Software Architecture Part 1.ppt
 
Chap 6 - Software Architecture Part 1.pptx
Chap 6 - Software Architecture Part 1.pptxChap 6 - Software Architecture Part 1.pptx
Chap 6 - Software Architecture Part 1.pptx
 
Software cracking and patching
Software cracking and patchingSoftware cracking and patching
Software cracking and patching
 
An Introduction To Model  View  Controller In XPages
An Introduction To Model  View  Controller In XPagesAn Introduction To Model  View  Controller In XPages
An Introduction To Model  View  Controller In XPages
 
2019-Nov: Domain Driven Design (DDD) and when not to use it
2019-Nov: Domain Driven Design (DDD) and when not to use it2019-Nov: Domain Driven Design (DDD) and when not to use it
2019-Nov: Domain Driven Design (DDD) and when not to use it
 
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...Designing and Implementing Information Systems with Event Modeling, Bobby Cal...
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...
 
Software Engineering (Introduction to Software Engineering)
Software Engineering (Introduction to Software Engineering)Software Engineering (Introduction to Software Engineering)
Software Engineering (Introduction to Software Engineering)
 
Technical stories v1.2
Technical stories v1.2Technical stories v1.2
Technical stories v1.2
 
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...
 

Recently uploaded

A Deep Dive into Secure Product Development Frameworks.pdf
A Deep Dive into Secure Product Development Frameworks.pdfA Deep Dive into Secure Product Development Frameworks.pdf
A Deep Dive into Secure Product Development Frameworks.pdfICS
 
Lessons Learned from Building a Serverless Notifications System.pdf
Lessons Learned from Building a Serverless Notifications System.pdfLessons Learned from Building a Serverless Notifications System.pdf
Lessons Learned from Building a Serverless Notifications System.pdfSrushith Repakula
 
^Clinic ^%[+27788225528*Abortion Pills For Sale In harare
^Clinic ^%[+27788225528*Abortion Pills For Sale In harare^Clinic ^%[+27788225528*Abortion Pills For Sale In harare
^Clinic ^%[+27788225528*Abortion Pills For Sale In hararekasambamuno
 
COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...
COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...
COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...naitiksharma1124
 
GraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4jGraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4jNeo4j
 
Software Engineering - Introduction + Process Models + Requirements Engineering
Software Engineering - Introduction + Process Models + Requirements EngineeringSoftware Engineering - Introduction + Process Models + Requirements Engineering
Software Engineering - Introduction + Process Models + Requirements EngineeringPrakhyath Rai
 
^Clinic ^%[+27788225528*Abortion Pills For Sale In witbank
^Clinic ^%[+27788225528*Abortion Pills For Sale In witbank^Clinic ^%[+27788225528*Abortion Pills For Sale In witbank
^Clinic ^%[+27788225528*Abortion Pills For Sale In witbankkasambamuno
 
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024SimonedeGijt
 
^Clinic ^%[+27788225528*Abortion Pills For Sale In soweto
^Clinic ^%[+27788225528*Abortion Pills For Sale In soweto^Clinic ^%[+27788225528*Abortion Pills For Sale In soweto
^Clinic ^%[+27788225528*Abortion Pills For Sale In sowetokasambamuno
 
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-Cloud
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-CloudAlluxio Monthly Webinar | Simplify Data Access for AI in Multi-Cloud
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-CloudAlluxio, Inc.
 
architecting-ai-in-the-enterprise-apis-and-applications.pdf
architecting-ai-in-the-enterprise-apis-and-applications.pdfarchitecting-ai-in-the-enterprise-apis-and-applications.pdf
architecting-ai-in-the-enterprise-apis-and-applications.pdfWSO2
 
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...Neo4j
 
Automate your OpenSIPS config tests - OpenSIPS Summit 2024
Automate your OpenSIPS config tests - OpenSIPS Summit 2024Automate your OpenSIPS config tests - OpenSIPS Summit 2024
Automate your OpenSIPS config tests - OpenSIPS Summit 2024Andreas Granig
 
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024MulesoftMunichMeetup
 
The Evolution of Web App Testing_ An Ultimate Guide to Future Trends.pdf
The Evolution of Web App Testing_ An Ultimate Guide to Future Trends.pdfThe Evolution of Web App Testing_ An Ultimate Guide to Future Trends.pdf
The Evolution of Web App Testing_ An Ultimate Guide to Future Trends.pdfkalichargn70th171
 
Transformer Neural Network Use Cases with Links
Transformer Neural Network Use Cases with LinksTransformer Neural Network Use Cases with Links
Transformer Neural Network Use Cases with LinksJinanKordab
 
Prompt Engineering - an Art, a Science, or your next Job Title?
Prompt Engineering - an Art, a Science, or your next Job Title?Prompt Engineering - an Art, a Science, or your next Job Title?
Prompt Engineering - an Art, a Science, or your next Job Title?Maxim Salnikov
 
Effective Strategies for Wix's Scaling challenges - GeeCon
Effective Strategies for Wix's Scaling challenges - GeeConEffective Strategies for Wix's Scaling challenges - GeeCon
Effective Strategies for Wix's Scaling challenges - GeeConNatan Silnitsky
 
OpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCAOpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCAShane Coughlan
 

Recently uploaded (20)

A Deep Dive into Secure Product Development Frameworks.pdf
A Deep Dive into Secure Product Development Frameworks.pdfA Deep Dive into Secure Product Development Frameworks.pdf
A Deep Dive into Secure Product Development Frameworks.pdf
 
Lessons Learned from Building a Serverless Notifications System.pdf
Lessons Learned from Building a Serverless Notifications System.pdfLessons Learned from Building a Serverless Notifications System.pdf
Lessons Learned from Building a Serverless Notifications System.pdf
 
^Clinic ^%[+27788225528*Abortion Pills For Sale In harare
^Clinic ^%[+27788225528*Abortion Pills For Sale In harare^Clinic ^%[+27788225528*Abortion Pills For Sale In harare
^Clinic ^%[+27788225528*Abortion Pills For Sale In harare
 
COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...
COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...
COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...
 
GraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4jGraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4j
 
Software Engineering - Introduction + Process Models + Requirements Engineering
Software Engineering - Introduction + Process Models + Requirements EngineeringSoftware Engineering - Introduction + Process Models + Requirements Engineering
Software Engineering - Introduction + Process Models + Requirements Engineering
 
^Clinic ^%[+27788225528*Abortion Pills For Sale In witbank
^Clinic ^%[+27788225528*Abortion Pills For Sale In witbank^Clinic ^%[+27788225528*Abortion Pills For Sale In witbank
^Clinic ^%[+27788225528*Abortion Pills For Sale In witbank
 
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024
Wired_2.0_CREATE YOUR ULTIMATE LEARNING ENVIRONMENT_JCON_16052024
 
^Clinic ^%[+27788225528*Abortion Pills For Sale In soweto
^Clinic ^%[+27788225528*Abortion Pills For Sale In soweto^Clinic ^%[+27788225528*Abortion Pills For Sale In soweto
^Clinic ^%[+27788225528*Abortion Pills For Sale In soweto
 
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-Cloud
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-CloudAlluxio Monthly Webinar | Simplify Data Access for AI in Multi-Cloud
Alluxio Monthly Webinar | Simplify Data Access for AI in Multi-Cloud
 
Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...
Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...
Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...
 
architecting-ai-in-the-enterprise-apis-and-applications.pdf
architecting-ai-in-the-enterprise-apis-and-applications.pdfarchitecting-ai-in-the-enterprise-apis-and-applications.pdf
architecting-ai-in-the-enterprise-apis-and-applications.pdf
 
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...
 
Automate your OpenSIPS config tests - OpenSIPS Summit 2024
Automate your OpenSIPS config tests - OpenSIPS Summit 2024Automate your OpenSIPS config tests - OpenSIPS Summit 2024
Automate your OpenSIPS config tests - OpenSIPS Summit 2024
 
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024
Anypoint Code Builder - Munich MuleSoft Meetup - 16th May 2024
 
The Evolution of Web App Testing_ An Ultimate Guide to Future Trends.pdf
The Evolution of Web App Testing_ An Ultimate Guide to Future Trends.pdfThe Evolution of Web App Testing_ An Ultimate Guide to Future Trends.pdf
The Evolution of Web App Testing_ An Ultimate Guide to Future Trends.pdf
 
Transformer Neural Network Use Cases with Links
Transformer Neural Network Use Cases with LinksTransformer Neural Network Use Cases with Links
Transformer Neural Network Use Cases with Links
 
Prompt Engineering - an Art, a Science, or your next Job Title?
Prompt Engineering - an Art, a Science, or your next Job Title?Prompt Engineering - an Art, a Science, or your next Job Title?
Prompt Engineering - an Art, a Science, or your next Job Title?
 
Effective Strategies for Wix's Scaling challenges - GeeCon
Effective Strategies for Wix's Scaling challenges - GeeConEffective Strategies for Wix's Scaling challenges - GeeCon
Effective Strategies for Wix's Scaling challenges - GeeCon
 
OpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCAOpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCA
 

Deep Dive into the Idea of Software Architecture

  • 1. Introduction and deep dive into the idea of Software Architecture Matt Clarke - Genesis Energy - Sep 2018
  • 2.
  • 3. 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
  • 5. 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?
  • 6. • 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
  • 8. 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?
  • 9. What does a badly- architected project look like?
  • 10.
  • 11.
  • 12. 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
  • 13. But why are any of these things necessarily bad?
  • 14. 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
  • 15. 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
  • 16. "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!"
  • 17. 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
  • 18. “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.”
  • 19. 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?
  • 20.
  • 21. 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
  • 22. 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)
  • 23.
  • 24. 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.”
  • 25. 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?
  • 26. 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)
  • 27. 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
  • 28.
  • 29. Types of software boundaries • Function • Class • Interface • Package/directory • Module • Library • Process on the same machine • Process on another machine (API boundary)
  • 30. 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
  • 32. Boundary <-> abstraction public interface MusicPlayer { void play(); void pause(); void stop(); void next(); void previous(); }
  • 33. 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?
  • 34.
  • 35. 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
  • 36. 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
  • 37. 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
  • 38. Layered Architecture • What are some classes of changes that commonly occur at the same time? • 3 tier architecture: Presentation/UI Domain/Business Data
  • 39. 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
  • 40. 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…
  • 41. Layered Architecture Presentation/UI Domain/Business Data Login Elec. Gas LPG Bills presentation/
 login/
 electricity/
 gas/
 domain/
 login/
 electricity/
 gas/
 data/
 login/
 electricity/
 gas/
  • 42. Layered Architecture Presentation/UI Domain/Business Data Login Elec. Gas LPG Bills login/
 presentation/
 domain/
 data/
 electricity/
 presentation/
 domain/
 data/
 gas/
 presentation/
 domain/
 data/
  • 43.
  • 44.
  • 45. 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.”
  • 46. Agile Parallel • Dependency Rule -> the Clean Architecture • Agile principles -> Scrum