Software architecture, methodologies and design

Agenda:
- Software architecture overview
- Software development methodologies overview
- Design and modeling principles overview
- Architectural patterns overview
- Q and A

What is Software
Architecture?

The highest possible concept of a
software system in its
environment ...
Martin Fowler:
https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

The highest level concept of the
expert developers ...
Martin Fowler:

I define architecture as a word we
use when we want to talk about
design but want to puff it up to
make it sound important.
Martin Fowler:

Architecture is about the
important stuff.
Whatever that is!!!
Ralph Johnson

It is not architecture if there is no
boxes and lines ...
Simon Brown

“Cargo - cult”:
ritual way of doing stuff without
deeper (or any) understanding -
just because it’s cool and trendy
https://en.wikipedia.org/wiki/Cargo_cult_programming

Side by side comparison and
analogy with C4 software and
architecture visualisation system
(by Simon Brown)

C4 visualisation of architecture: http://static.codingthearchitecture.com/c4.pdf
C1 zoom level: Software Context
- Users interacting with the system
- System in center surrounded by users to describe context in which
system is used
- Broader picture which non tech people can understand

C2 zoom level: Containers
- Illustration of high level tech choices in which system runs, such as:
- Web applications
- Web services
- System services
- Databases, file systems, etc...

C3 zoom level: Components
- Major structural building blocks contained within container
- Component: an encapsulated unit of software that has a well deﬁned
interface and a clear and concise role and responsibility statement

C4 zoom level: Classes or Code
- Can be visualized with UML or whatever it makes sense
C3 zoom level: Components

Comparing C4 to abstract/conceptual design and architectural concept
C1: Context
C2: Containers
C3: Components
C4: Classes
Software System visualisation
Software Architecture and Design on
conceptual abstract level - zoom level
matches?
?

C1: Context
C2: Containers
C3: Components
C4: Classes
C1: Architectural Context
- Set of targeted quality attributes expected from a
system
- Also known as “itties” - scalability, maintanability,
testability ...
- Usually three primary (must have) and three
secondary (nice to have)
- https://en.wikipedia.org/wiki/List_of_system_quality_
attributes
-

accessibility evolvability repeatability accountability extensibility reproducibility
accuracy failure transparency resilience adaptability fault-tolerance
responsiveness administrability fidelity reusability affordability flexibility
robustness agility inspectability safety auditability installability scalability
autonomy integrity seamlessness availability interchangeability
self-sustainability compatibility interoperability serviceability composability
learnability supportability configurability maintainability securability
correctness manageability simplicity credibility mobility stability
customizability modifiability standards compliance debugability modularity
survivability degradability operability sustainability determinability orthogonality
tailorability demonstrability portability testability dependability precision
timeliness deployability predictability traceability discoverability process
capabilities transparency distributability producibility ubiquity durability
provability understandability effectiveness recoverability upgradability
efficiency relevance usability

- "over time we are expecting the entire company to use
this system" - ?
- "the budget and timeframe for this system is very, very
tight" - ?
- "we need lightning-fast response time to keep up with
the backlog of calls" - ?
- "we are planning to acquire several businesses in the
next 5 years" - ?

- "over time we are expecting the entire company to use
this system" - scalability
- "the budget and timeframe for this system is very, very
tight" - feasibility
- "we need lightning-fast response time to keep up with
the backlog of calls" - performance
- "we are planning to acquire several businesses in the
next 5 years" - extensibility, agility, maintainability

Enterprise software or Line of Business software common
architectural contexts:
- Reliability (or less fragility)
- Testability
- Flexibility (or less rigidity)
- Reusability and modularity
- Maintainability - stability, analyzability, readability,
changeability, testability

Consequences of ignoring architectural context and quality
attributes

C1: Context
C2: Containers
C3: Components
C4: Classes
C2: Architectural patterns/style classification
- Big Ball of Mud
- Monolithic: Layered, Microkernel, Pipeline...
- Distributed: Event-driven, Space-based,
Service-oriented, Service-based, Microservices...
- Hybrids: Event-driven layered, Layered-microkernel,
many, many different combination…
- Highly specialized architecture: LMAX

Big Ball of Mud - absence of any perceivable architecture

Layered architecture
- Separation of Concerns
- Cross cutting concerns?
- Open or closed layers?
- Service Layer?
- Physical Tiers and scalability?
- Vertical decomposition strategies?
(functional, velocity of change,
bounded context, CQRS ...)

Microkernel (plug-in) architecture
- Core - minimal logic to run the system and
business logic
- Plug in - standalone independent module
with additional logic
- Example - claims processing, each state
with own plug in
- modern browsers implementations
- Business applications

Event-driven architecture
- Broker topology - message
queue
- vs
- Mediator topology - series of
parallel events
- Transaction problem
- Delphi Corba

Pipeline architecture
- Self contained and independent
from other filters
- Designed to perform single task
- Four types of filters
- Example: Captures data from
different sources and multiple
formats and, process them and
sends them to output

Space-based architecture
- Separate, independent, scalable processing units
- Middleware manages: input and sessions, data
replication, distributed request processing,
dynamic deployment
- Commercial implementations: javaspaces,
gigaspaces, ibm object grid, oracle coherence…
- All about variable scalability (variable load or
inconsistent peak times)
- Not good for traditional relational db systems and
complex and expensive

Microservices architecture
- Distributed - Protocol aware heterogeneous
interoperability (Java, .net, python, etc)
- Separately deployed
- Service components (functional services,
infrastructure services, messaging services)
- Bounded context (common, ubiquitous language )
- Data domains (no acid transactions, replication or
nosql)
- Api layer (http or lightweight messaging)
- Event driven or pipeline

Service-oriented architecture
- Distributed: Protocol agnostic heterogeneous
interoperability
- Contract decoupling
- Integration server (integrability, b2b)
- Good for large organizations with lots of legacy
systems
- Commercial implementations: MS BizTalk, IBM
WebSphere

Service-based architecture - let’s find some middle ground between SOA and
Microservices

Service-based architecture
Advantages:
- Unit of Work transactional context
- Performance and robustness
(joins, orchestration)
- Domain scope
- Shared resources
- Feasibility
Tradeoffs:
- Service deployment and testing
- Deployment pipeline planning
- Change control
- Bounded context
- Couplings, schema changes

Service-based architecture - transition to microservices

C1: Context
C2: Containers
C3: Components
C4: Classes
C3: Architectural Patterns
- Transactional script
- Active Record and Data Mapper
- Data Repositories and Units of Work
- Domain Models
- Model View Whatever (MVC, MVP, MVVP, …)

C1: Context
C2: Containers
C3: Components
C4: Classes
C4: Design patterns
- Creational: Factory, Abstract Factory, Dependency
Injection, Singletons, etc...
- Structural: Adapter, Proxy, Facade, Manager,
Composite, Decorator, etc...
- Behavioral: Command, Iterator, Mediator, Strategy, ...
- Concurrency: Thread-pool, Lock, Join, Double-check
locking, etc...
- Lots of criticism and lots of cargo-cult -
https://gist.github.com/jaysonrowe/1592775 vs
https://github.com/EnterpriseQualityCoding/FizzBuzzE
nterpriseEdition
-

module
1. Database First (bottom-up)
db
module module
module
ui
- Most common methodology - strong
emphasis on database design
- Starts with modeling your storage device
schema
- Relational database is optimized for easy or
optimized general purpose querying not for
actual solution
- Awkward object models of actual solution
(domain) - impedance mismatch problem

2. DDD: Domain-driven development (top-down)
db
repositories
ui
Domain model
- DDD starts with development of domain model first.
- Domain model is object oriented (in-memory) model of solution
of your problem (business object model)
- Developed without second thought how data
should be persisted - db schema is modeled at
the end, after the domain, domain is persistence
ignorant, - don’t know and even don’t care
anything about db schema
- db model derives from domain schema and it is modeled to
accommodate domain object model persistence
- Repository pattern is used to communicate to database (object
are put to and retrieved from repositories)
- Test Driven Development - TDD - can be applied from start!
view models

3. TDD: Test-driven development
RED
GREEN
REFACTOR
1. Write a failing test - red
2. Write just enough code to
make your failing test pass -
green
3. Refactor your code to make it better - apply modeling
principles or project guidelines and standards - your test is
red again
4. Repeat everything
until results are
satisfactory

Development Modeling
Principles

Low coupling and High cohesion
- Coupling: extent to which components know about
each other
- Types of coupling:
- Afferent - A, B and C are coupled to D
- Efferent - A is coupled to B, C and D
- Temporal - timing dependencies like transaction
A B C
A B C

- Coupling: extent to which components know about
each other
- Degrees of coupling:
1) Tight coupling (pathological coupling) - depending on inner workings
of component or system
2) External coupling - components share externally imposed protocol
(rest, soap)
3) Control coupling - one component passes info to others what to do
4) Loose coupling - data coupling - components are bound to shared
data context
A B C
A B C

- Cohesion:
1) Degree to which the components belong together, suggestion is all the
related code should be close to each other
2) How clear is component responsibility:
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition/tre
e/master/src/main/java/com/seriouscompany/business/java/fizzbuzz/pack
agenamingpackage/impl/stringreturners

GOF: Program to an interface - not to
implementation
- Classes should aware only of interface and not of
implementation
- It means your code should operate on interfaces rather
than concrete objects with concrete implementation
- We should avoid pathological coupling -
depending on inner workings of component
or system
- Makes your code much more flexible
interface
Impl. 1. Impl. 2. Impl. N.
Client
code

GOF: Favor composition to inheritance
- Derived is tightly coupled to base - they are
in “is a” relationship
- Base class exposes it’s private parts to
derived - breaks encapsulation
- Composition is “has a” relationship - it can
be replaced any time - it is much more
loosely coupled.
base
derived
Composed
(owned)
Composer
(owner)

S.O.L.I.D. principles
When applied together, it is more likely that a programmer will create a system
that is easy to maintain and extend over time.
- SRP, OCP, LSP, ISP, DIP
- Robert C. Martin, aka Uncle Bob

SRP - Single Responsibility Principle
- A class should have only ONE reason to change or ONE, single, and CLEAR
responsibility!
- Methods have intent or intention, classes have responsibility!
responsibility
intent

- Responsibility = reason to change (not being bugfix or refactoring)
- Responsibility = it is an axis of change.
- If there are more than one reason to change, more than one motive to change or it changes on
different occasion for different reason - violates SRP
- Things that change for same reasons belong into same class!
- Each of those responsibilities could change from different reason in different time - and on every
single change we have to deal with each and every piece of code of ALL of those responsibilities.
- That reeks on rigidity - harder to change!
- Also reeks on fragility - that change can cause undesired behavior on
unexpected places!

- Textbook example:
- We need to calculate some value using certain algorithm using some values stored in database
- How many responsibilites are there?

- Textbook example 2:
- We have two separate and different views that will be showing same data using same query:
View A View B
Query X Query X
OR?
View A View B
Query X
Changeability, agility? Fragility, changeability, testability,
analyzability, stability?

- Uncle Bob: Axis of change is only if change actually happens.
Small, over-fragmented classes smell on needless complexity and lack of
cohesion!
- Java FizzBuzz enterprise example of needless complexity and lack of cohesion
- Classes can and should do different things if they all lay on same axis of change.
On the other hand…
- The “god object” or the “monster object” is offensive anti-pattern - class that
has too many functionalities implemented, like a swiss knife.
- When something breaks, and it will, you might lose your entire toolset.

- The right balance between needles complexity and violation of SRP:
- Experience
- Feedback from domain expert
- Class-responsibility-collaboration card or CRC cards in design process

OCP - Open-Closed Principle
- Software entities (modules, classes, functions) - should
be open for extension and closed for modifications
- OR:
1) Code is opened to extension
2) Code is closed for modifications
- No code lives in total isolation - complete decoupling is not possible.
- So, when change happens, and it will - it may cascade through dependent modules and cause
undesired behaviour.
We want to prevent fragility.

- Abstraction is the key for this principle.
- To be able to make class extendable with new code, abstraction is used - we
just insert layer of abstraction between code we want to protect from
changes and the calling code.
- Textbook example:
- Geometrical drawing application. Drawing different geometrical shapes on
screen - square, circle, rectangle, triangle …

So, can we close all code for changes?

- Trying to close all closures is offensive anti-pattern -
over-engineering.
- Since, we cannot and should not close all closures -
closures need to be strategic - strategic closure!
- Example - calling function to determine is service available

- How can we detect strategic closures?
- Experience
- Feedback from domain expert
- CRC cards and upright design process

- Design pattern examples that allows us closing code for modifications:
- Facade design pattern - simplified interface for larger
body of code such as service or library
- Proxy design pattern - interface for something else
- Adapter design pattern - allows some interface to be
used as another interface

LSP - Liskov Substitution Principle
- Functions that use pointers or references to base classes
must be able to use objects of derived classes without
knowing it.
- Wants to tell us something important about inheritance:
- Object instance from base and derived classes must be
replaceable!
- Inheritance should be “is substitution for” instead of “is” relation

- Breaking the LSP will also break an OCP principle
- If introduce derived class, for which we need to modify calling code - that
modification can easily cascade through system and dependent modules
bringing unwanted undesired behaviour and errors.
- If we use “is instance” type operators to form conditional statements - that is
strong indication of LSP violation - and, OCP is also violated where that type
operator is used!

Square
+ SetWidth()
+ SetHeight()
+ CalcArea()
Rectangle
+ SetWidth()
+ SetHeight()
+ CalcArea()
OR?
Rectangle
+ SetWidth()
+ SetHeight()
+ CalcArea()
Square
+ SetSide()
Calculable Area
(abstract)
+ CalcArea()

ISP - Interface Segregation Principle
- Clients should NOT be forced to depend upon
interfaces that they do not use!
- This principle deals with disadvantages of having so called “fat”
interfaces”.
- We don’t want “fat” interfaces! We want only what we use!
- No-one should be forced to depend on what it doesn’t use!

- Same basic idea as SRP but from different angle:
- Unlike SRP which states that each module should
have one responsibility - ISP is tells us not to be
confronted with something that you might not actually
need.

DIP - Dependency Inversion Principle
a) High level modules should NOT depend on low level
modules. Both should depend on abstraction.
b) Abstraction should NOT depend upon details. Details
should depend upon abstraction.

- Same basic idea as OCP, but, it tells us exactly what
our strategic closure should be - module level
- Between modules there should be layer of abstraction
upon both modules depend, rather on each other
directly.
- This is the principle that is at the very heart of
frameworks design.

- And in case of enterprise architecture - that is exactly
what we are trying to accomplish - to create framework
for our enterprise or business!
- It is at the root of many of the benefits claimed for
object-oriented technology.

Copy
Keyboard
reader
Printer
writer
- Can you test “copy” without Keyboard reader or Printer writer?
- Can you replace Keyboard reader with some custom File reader?
- Can you replace Printer writer with with some custom File writer?

Copy
Reader
(abstract)
Writer
(abstract)
Keyboard
reader
Printer
writer
- Higher level module - copy
- Lower level modules - keyboard reader and
printer writer
- Abstraction - abstract reader and writer
- Details - higher level module and lower level
modules
- Abstraction doesn’t depend on anyone or
anything.
- Details depend on abstraction, not on each other -
dependency structure is inverted.

- Can be used whenever two pieces of code talk to each other - to be able
to supply alternative implementation dynamically!
- Makes your code reliable, flexible, reusable and maintainable.
- Essential part of good design

Dependency Injection (DI) and Inversion of
Control (IOC) - Hollywood Principle
- if we use dependency inversion - how that dependency should be
supplied to a higher level module or a class?
- Also, where are those classes are supposed to be created then?

Injection:
- Property injection
(is this abomination?)
- Method injection
- Constructor injection

Creation:
- Poor man’s DI - default parameters (not really
decoupled)
- Factory design pattern
- Service locator design pattern

Creation:
- Note:
- Created dependencies can be really really complex,
and have its own complex dependencies and so
on…
- Those structures are usually called - Structure
Maps

Creation:
- Poor man’s DI - default parameters (not really
decoupled)
- Good to start with, simple structure maps

Creation:
- Factory design pattern, support more complex
structure maps
Client
code
Factory Created
objects
uses >> creates >>

Creation:
- Service Locator design pattern
Client
code
Service
locator
Service
instance
ABC
Service
instance
XYZ
Service
instance
123
uses >>

Creation: IoC Container - true followers of “Don’t call us, we’ll call you”
concept.
- Dependency is completely inverted, it is usually bootstrapped at
application startup from some kind of configuration file usually.
Usually some 3rd party library, but not necessarily.
By using an IoC Container, the client code can simply depend on an interface
or abstract class and not have a care in the world as to what is providing it
with the concrete implementation at runtime.

factories
service locators
configuration /
containers
main
concrete implementations
app. services
domain objects
main / init / global
application

SOC - Separation of Concerns
- Concern - module level
- Responsibility - class level
- Intent - method level
- Concern = Any piece of interest or focus in our
program!
- We can or we should focus our
attention on one focus or one
aspect at the time.
concern
responsibility
intent

storage
device
Your code
ui
device
storage
device
ui
device
ui device
concern
Your app
logic
Storage
concern
Presentation / UI layer
Business / Domain layer
Persistence / Data Access layer
Database
layer
ui

Persistence / Data Access layer
- Relations models
- Repositories, Units of Works, Query
Builders
- ORM’s and Queries
Presentation / UI
layer
View Models
Business / Domain layer
- Domain models, domain entities, value
objects, factories, processors and
managers
- Loose coupled with pub/subs
Database
layer
- Conways law
- Schema changes containment and logic
duplication
- Change management, rate of change, different
motivations and deployment
- Cross cutting concerns?
- Service Layer?
- DI between layers?
- Service separation and tiers
- Vertical decomposition strategies:
- Functional
- Velocity and value streams
- Bounded context
- Command and query segregation
Service layer
Messages,
Request/Response
models

Transactional Script Architectural Pattern
- Transactionional Script Strengths
- Simple, easy and fast to develop
- Suitable for small schemas
- Transactionional Script Weaknesses
- Hard or impossible to test
- Procedural style, no modelling
- Hard to compensate schema changes

Active Record and Data Mapper
- Active Record, Data Mapper and ORM’s
- Differences and Strengths
- Weaknesses and Impedance Mismatch

Active Record, Data Mapper, ORM’s
- Is it real abstraction or just mapping?
- Vietnam of Computer Science
- Some examples of strange manifestations of
Impedance Mismatch

Domain models, domain modeling and some
other architectural patterns
- Domain models, Anemic Domain Models, Identity
objects, Value objects and Bounded Context
- Data Repositories, Aggregate roots
- Presentation patterns, Service patterns, etc...

Some resources
- https://www.thoughtworks.com/ - global consultancy company, anything from them
- Neal Ford: http://nealford.com/ - software architecture consultant at thoughtworks, books, videos, lectures
and workshops
- Martin Fowler, chief scientist at thoughtworks, books, videos, lectures
- Juval Löwy, software legend, ceo and founder of IDesign - http://www.idesign.net/ - consultancy, lectures,
videos, workshops
- Simon Brown - http://simonbrown.je/ consultancy, visualization software, videos, lectures
- Many other consultants in the field that offer lectures, books, free videos, etc, like Mark Richards, Dino
Esposito, Allen Holub, etc…
- Listen to the software architecture radio: http://www.softwarearchitecturerad.io/
Thank you for your attention

Software architecture, methodologies and design

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Software architecture, methodologies and design

Similaire à Software architecture, methodologies and design (20)

Dernier

Dernier (20)

Software architecture, methodologies and design