Software Architecture Taxonomies - modularity

Arquitectura del Software
Escuela de Ingeniería Informática Universidad de Oviedo
Universidad de Oviedo
Software Architecture
Part II. Architecture classifications
3 - Modularity
2014 Jose Emilio Labra Gayo

Modularity

Big Ball of Mud
Hierarchical decomposition
Dependencies
Generalization
Layers
Aspect Oriented decomposition
Domain based decomposition

Big Ball of Mud
Big Ball of Mud
Described by Foote & Yoder, 1997
Elements
Lots of entities intertwined
Constraints
None

Big Ball of Mud
Advantages
Quick-start
It is possible to start without defining an architecture
Solve problems on demand
Cheap solution for short-term projects
It can be OK for some projects

Big Ball of Mud
Problems
High Maintenance costs
Low flexibility from a given point
At start it can be very flexible
After some time, a change can be dramatic
Inertia
When the system becomes a Big Ball of Mud it is very
difficult to convert it to another thing
A few prestigious developers know where to touch
Clean developers run away from these systems

Big Ball of Mud
Some reasons
Throwaway code:
You need an immediate fix for a small problem, a
quick prototype or proof of concept
When it is good enough, you ship it
Piecemeal growth
Cut/Paste reuse
Bad code is reproduced in lots of places
Anti-patterns
Bad smells
Code/Architecture

Modular decomposition
Elements
Modules
Each module has an interface and a body
Relationships "is part of" between modules

Definitions
Module:
Piece of software the offers a set of responsabilities
It makes sense at development time (no runtime)
Separates interface from body
Interface
Describes what is a module
How to use it  Contract
Body
How it is implemented
Interface
Body
(Implementation)
Module

Quality attributes
Commnication
Communicates the general aspect of the system
Minimizes complexity
A module only exposes an interface
Extensibility, maintenance
Facilitates changes and extensions
Localized functionality
Reusability
Modules can be used in other contexts
Product lines
Independence
Modules can be developed by different teams

Challenges
Bad decomposition can augment complexity
Decission: Develop vs buy
COTS modules
Dependency management
Third parties modules can affect evolution
Team organization
Modular decomposition can affect team development
and organization

Constraints
No cycles are allowed
A module can only have one parent
System
Subsystem
A
Subsystem
B
Subsystem
B1
Subsystem
B2
Subsystem
A2
Subsystem
A1

Some recommendations
High cohesion
Low coupling
SOLID principles
Demeter's Law
Fluid interfaces

Modularity recommendations
High cohesion
Cohesion = Coherence of a module
Each module must solve one functionality
DRY (Don't Repeat Yourself) Principle
Intention must be declared in only one place
It should be possible to test each module separately

Low coupling
Coupling = Interaction degree between modules
Low coupling  Improves modifiability
Independent deployment of each module
Stability against changes in other modules

SOLID principles
They can be used to define clases and modules
SRP (Single Responsability Principle)
OCP (Open-Closed Principle)
LSP (Liskov Substitution Principle)
ISP (Interface Seggregation Principle)
DIP (Dependency Injection Principle)

(S)ingle Responsibility
A module must have one responsibility
Responsibility = A reason to change
No more than one reason to change a module
Otherwise, responsibilities are mixed and coupling increases
vs

(S)ingle Resposibility
class Employee {
def calculatePay(): Money = { ??? }
def saveDB() { ??? }
def reportWorkingHours(): String = { ??? }
Responsible departments
http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
}
Financial department
Operations
Management
There can be multiple reasons to change the Employee class
Solution: Separate concerns
Gather together the things that change for the same reasons.
Separate those things that change for different reasons.

(O)pen/Closed principle
Open for extension
The module must adapt to new changes
Change/adapt the behavior of a module
Closed for modification
Changes can be done without changing the module
Without modifying source code, binaries, etc
It should be easy to change the behaviour of a module without
changing the source code of that module
http://blog.8thlight.com/uncle-bob/2013/03/08/AnOpenAndClosedCase.html

(O)pen/Closed principle
Example:
class SelectProducts {
def filterByColor(products: List[Product],
color: Color): List[Product] = {
???
}
If you need to filter by height, you need to change the source code
Another solution:
def filter(products: List[Product],
predicate: Product => Boolean): List[Product] = {
???
}
Now, it is possible to filter by any predicate without changing the module

(L)iskov Substitution
Subtypes must follow supertypes contract
A type B is a subtype of A when:
xA, if there is a property Q such that Q(x)
then yB, Q(y)
A
B
"Derived types must be completely substitutable by their base types"
Common mistakes:
Inherit and modify behaviour of base class
Add functionality to supertypes that subtypes don't follow

(L)iskov Substitution
Duck
haceCuak
tieneFormaPato
respira)
doCuak
hasShapeDuck
breathes)
X
Example
DuckInPark RubberDucky

(I)nterface Segregation
Clients must not depend on unused methods
Better to have small and cohesive interfaces
Otherwise  non desired dependencies
If a module depends on non-used functionalities and these
functionalities change, the module can be effected
ClientA
ClientB
InterfaceA
methodA1
methodA2
InterfaceB
methodB1
methodB2
Service
mehtodA1
methodA2
methodB1
methodB2
...
<<uses>>
<<uses>>

(D)ependency Inversion
Invert conventional dependencies
High-level modules should not depend on low-level modules
Both should depend on abstractions
Abstractions should not depend upon details.
Details should depend upon abstractions
Can be accomplished using dependency injection or
several patterns like plugin, service locator, etc.
http://www.objectmentor.com/resources/articles/dip.pdf
http://martinfowler.com/articles/dipInTheWild.html

(D)ependency Inversion
Lowers coupling
Facilitates unit testing
Substituting low level modules by test doubles
Related with:
Dependency injection and Inversion of Control
Frameworks: Spring, Guice, etc.

Demeter's Law
Principle of less knowledge
Modules only communicates with near modules
Goal: low coupling
Lower number of invoked methods
Tradeoff solution
It is not always possitive
It can augment number of methods in modules
Symptoms of bad design:
Using more than one dot...
a.b.method(...) 


Fluent APIs
Improve readability and usability of interfaces
Advantages
Can lead to domain specific languages
Auto-complete facilities by IDEs

Fluent APIs
Methods that modify return the same object
class Product {
...
public Product setPrice(double price) {
this.price = price;
return this;
};
Several methods can be chained
Example:
Product p = new Product().
setName("Pepe").
setPrice(23);
It does not contradict Demeter's Law because it acts on the same object

Other modularity recommendations
Facilitate external configuration of a module
Create an external configuration module
Create a default implementation
GRASP Principles
General Responsibility Assignment Software Patterns

Module Systems
In Java:
OSGi
Module = bundle
Controls encapsulation
It allows to install, start, stop and deinstall modules
during runtime
Used in Eclipse
Modules = Micro-services
Several implementations: Apache Felix, Equinox
Jigsaw Project (Java 9)
In .Net: Assemblies

Module Dependencies
Relationship "uses"
One module uses (depends on) other module

Module Dependencies
Elementes
Modules
Relationships "depends on" between modules
Constraints
Module M1 depends on M2 if correct behavior of M1
depends on correct behavior of M2

Module Dependencies
Advantages:
Incremental development
Implement part of the functionality
Debugging, testing
Facilitates impact analysis upon changes

Module dependencies
Challenges
Dependency management
Avoid cyclic dependencies
Modules that depend on a lot of modules
Limits incremental development
Bad separation of concerns

Generalization/specialization
Elements
Modules
Relationships (is-a) between
modules
Constraints:
Parent is more general than
children

Generalization/Specialization
Advantages
Facilitates extensión and architecture evolution
Notion of inheritance in OO design
Captures common parts with variations = children
Change and local variation
Reuse

Challenges
Complexity to identify relationships
Exceptions
Multiple inheritance implications

Applications
Application frameworks

Layers
Divide software modules in layers
Order between layers
Each layer exposes an interface that can be used
by higher layers
Layer N
Layer N - 1
. . .
Layer 1

Layers
Elements
Layer: set of functionalities exposed through an
interface at a level N
Order relationship between layers
Layer N
Layer N - 1
. . .
Layer 1

Capas
Constraints
Each software block belongs to one layer
There are at least 2 layers
A layer can be:
Client: consumes services from below layers
Server: provides services to upper layers
2 variants:
Strict: Layer N uses only functionality from layer N-1
Lax: Layer N uses functionalities from layers 1 to N - 1
No cycles

Layers
Example
User interface
Application
Domain
Infrastructure

Layers
Layers ≠ Modules
A layer can be a module...
...but modules can be decomposed in other modules
(layers can't)
Dividing a layer, it is posible to obtain modules

Layers
Layers ≠ Tiers
Layer: conceptual separation Tier: physical separation
Presentation
Business
Data
3-Layers
External
Applications
Legacy
systems
Database
Business
logic
Firewall
Thin
client
RIA
Presentation Business Data
3-tiers

Layers
Advantages
Separates different abstraction levels
Loose coupling: independent evolution of each layer
It is possible to offer different implementations of a
layer that keep the same interface
Reusability
Changes in a layer affects only to the layer that is
above or below it.
It is possible to create standard interfaces as libraries
or application frameworks

Layers
Challenges
It is notalways possible to apply it
Not always do we have different abstraction levels
Performance
Access through layers can slow the system
Shortcuts
Sometimes, it may be necessary to skip some layers

Layers
Example: Android

Layers
Variants:
Virtual machines, APIs
3-layers, N-layers

Virtual machine
Virtual machine = Opaque layer
Hides a specific OS implementation
One can only get Access through the public API
Program
API
Virtual Machine
Operating
System

Virtual machines
Advantages
Portability
Simplifies software development
Higher-level programming
Facilitates emulation
Challenges
Performance
JIT techniques
Computational overload generated by the new layer

Virtual machine
Applications
Programming languages
JVM: Java Virtual Machine
CLR .Net
Emulation software

3-layers (N-layers)
Conceptual decomposition
Presentation
Business logic
Data
Presentation
Business
Data

Aspect Oriented
Aspects:
Modules that implement crosscutting features
Presentation
Business
Data
Security
Monitorization
Logging
Aspects
Interntionalization

Aspect Oriented
Elements:
Crosscutting concern
Functionality that is required in several places of an
application
Examples: logging, monitorization, i18n, security,...
Generate tangling code
Aspect. Captures a crosscutting-concern in a module

Aspect Oriented
Example: Book flight seats
Several methods to do the booking:
Book a seat
Book a row
Book two consecutive seats
...
En each method:
Check permission (security)
Concurrence (block seats)
Transactions (do the whole operation in one step)
Create a log of the operation
...

Aspect Oriented
Traditional solution
class Plane {
void bookSeat(int row, int number) {
// ... Log book petition
// ... check autorization
// ... check free seat
// ... block seat
// ... start transition
// ... log start of operation
// ... Do booking
// ... Log end of operation
// ... Execute transaction or rollback
// ... Unblock
}
...
public void bookRow(int row) {
// ... More or less the same!!!!
...
Concurrence
Logging
Security
Transaction

Aspect Oriented
Structure
Core
Application
Logic
Crosscutting
Crosscutting
Crosscutting
concern
concern
concern
(aspect)
Aspect
compiler
(weaving)
Final
application

Aspect Oriented
Definitions
Join point: Point where an aspect
can be inserted
Aspect:
Contains:
Advice: defines the job of the aspect
Pointcut: where the aspect will be
introduced
It can match one or more join points
Join points
Pointcut
Running
Program
Advice

Aspect Oriented
Aspect example in @Aspectj
@Aspect
public class Security {
@Pointcut("execution(* org.example.Flight.book*(..))")
public void safeAccess() {}
@Before("safeAccess()")
public void authenticate(JoinPoint joinPoint) {
// Does the authentication
}
}
Methods book*
It is executed before
to invoke those
methods
It can Access to
information of the
joinPoint

Aspect Oriented
Constraints:
An aspect can affect one or more traditional modules
An aspect captures all the definitions of a
crosscutting-concern
The aspect must be inserted in the code
Tools for automatic introduction

Aspect Oriented
Advantages
Simpler design
Basic application is clean of crosscutting concerns
Facilitates system modifiability and maintenance
Crosscutting concerns are localized in a single module
Reuse
Crosscutting concerns can be reused in other systems

Aspect Oriented
Challenges
External tools are needed
Aspects compiler. Example: AspectJ
Other tools: Spring, JBoss
Debugging is more complex
A bug in one aspect module can have unknown
consequences in other modules
Program flow is more complex
Team development needs new skills
Not every developer knows aspect oriented programming

Aspect Oriented
Applications
AspectJ = Java extension with AOP
Guice = Dependency injection Framework
Spring = Enterprise framework with dependency
injection and AOP
Variants
DCI (Data-Context-Interaction): It is centered in
the identification of roles from use cases

Domain based
Domain driven design
Hexagonal architecture
Data centered
Patterns
CQRS
Event sourcing
Naked Objects

Data model vs domain model
Data models
Physical:
Data representation
Tables, columns, keys, ...
Logical:
Data structure
Entities and relationships
Domain models
Conceptual model of a
domain
Vocabulary and context
Entities, relationships
Behavior
Business rules

Domain based
Centered on the domain and the business logic
Goal: Anticipate and handle changes in domain
Collaboration between developers and domain
experts

Domain based
Elements
Domain model: formed by:
Context
Entities
Relationships
Application
Manipulates domain elements

Domain based
Constraints
Domain model is a clearly identified module
separated from other modules
Domain centered application
Application must adapt to domain model changes
No topological constraints

Domain based
Advantages:
Facilitates team communication
Ubiquitous language
Reflects domain structure
Address domain changes
Share and reuse models
Reinforce data quality and consistency
Facilitates system testing
It is possible to create testing doubles with fake
domain data

Domain based
Challenges:
Collaboration with domain experts
Stalled analysis phase
It is necessary to establish context boundaries
Technological dependency
Avoid domain models that depend on some specific
persistence technologies
Synchronization
Synchronize system with domain changes

Domain based
Variants
DDD - Domain driven design
Hexagonal style
Data centered
N-Layered Domain Driven Design
Related patterns:
CQRS (Command Query Responsibility Segregation)
Event Sourcing
Naked Objects

DDD - Domain Driven Design
General approach to software development
Proposed by Eric Evans (2004)
Connect the implementation to an evolving domain
Collaboration between technical and domain experts
Ubiquitous language
Common vocabulary shared by the experts and the
development team

Elements
Bounded context
Specifies the boundaries of the domain
Entities
An object with an identity
Value objects
Contain attributes but no identity
Aggregates
Collection of objects bound together by some root entity
Services
External operations

Constraints
Entities inside aggregates are only accessible
through the root entity
Value objects contain only attributes (immutables)

Advantages
Code organization
Identification of the main parts
Maintenance/evolution of the system
Facilitates refactoring
It adapts to Behaviour Driven Development
Team communication
Problem space
Domain experts
Solution space
Development team
Ubiquitous language

Challenges
Involve domain experts in development
It is not always possible
Apparent complexity
It adds some constraints to development
Useful for complex, non-trivial domains

Hexagonal style
Other names:
ports and adapters, onion, clean, etc.
Based on a clean Domain model
Infrastructures and frameworks are outside
Access through ports and adapters
Application
Adapter
Adapter
Adapter
Adapter
Adapter
Domain
model
port
port
http://alistair.cockburn.us/Hexagonal+architecture
http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
Adapter

Hexagonal style
Example
Traditional application in layers
Incorporates new services
Testing DB
Application
Adapter UI
DB
MySQL
Adapter DB2
Adapter
REST
Adapter
printer
Adapter DB1
External
Application
Domain
Model
API port
data port
DB
MongoDB
Adapter
DB testing

Hexagonal style
Elements
Domain model
Represents business logic: Entities and relationships
Plain Objects (POJOs: Plain Old Java Objects)
Ports
Communication interface
It can be: User, Database
Adapters
One adapter by each external element
Examples: REST, User, DB SQL, DB mock,...

Hexagonal style
Advantages
Understanding
Improves domain understanding
Timelessness
Less dependency on technologies and frameworks
Adaptability (time to market)
It is easier to adapt the application to changes in the
domain
Testability
It is possible to substitute real databases by mock databases

Hexagonal style
Challenges
It can be difficult to separate domain from the
persistence system
Lots of frameworks combine both
Asymmetry of ports & adapters
Not all are equal
Active ports (user) vs passive ports (logger)

Data centered
Simple domains based on data
CRUD (Create-Retrieve-Update-Delete) operations
Advantages:
Semi-automatic generation (scaffolding)
Rapid development (time-to-market)
Challenges
Evolution to more complex domains
Anemic domains
Classes that only contain getters/setters
Objects without behaviour (delegated to other layers)
Can be like procedural programming
Anemic Models: https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/

Domain based styles
3 patterns related
CQRS
Event Sourcing
Naked Objects

CQRS
Command Query Responsibility Segregation
Separate models in 2 parts
Command: Does changes (updates information)
Query: Only queries (get information)
Application
Model
User
Interface
Data
Base

CQRS
Command Query Responsibility Segregation
Separate models in 2 parts
Command: Does changes (updates information)
Query: Only queries (get information)
Application
Query
User
Interface
Data
Base
Command

CQRS
Advantages
Scalability
Optimize queries (read-only)
Asynchronous commands
Facilitates team decomposition and organization
1 team for read access (queries)
1 team for read/write access (command)

CQRS
Challenges
Hybrid operations (both query and command)
Example: pop() in a stack
Complexity
For simple CRUD applications it can be too complex
Synchronization
Possibility of queries over non-updated data
Applications
Axon Framework

Event Sourcing
All changes to application state are stored as a
sequence of events
Every change is captured in an event store
It is possible to trace and undo changes
Write
-------------------- -------------------- -------------------- ----------
Event
store
Event
Driver
Read
snapshots

Event Sourcing
Elements
Events: something that has happened, in the past
Event store: Events are always added (append-only)
Event driver: handles the different events
Snapshots of aggragated state (optional)
Write
-------------------- -------------------- -------------------- ----------
Event
store
Event
Driver
Read
snapshots

Event Sourcing
Advantages
Fault tolerance
Traceability
Determine the state of the application at any time
Rebuild and event-replay
It is possible to discard an application state and re-run
the events to rebuild a new state
Scalability
Append-only DB can be optimized

Event Sourcing
Challenges
Event handling
Synchronization, consistency
Complexity of development
It addes a new indirection level
Resource management
Event granularity
Event storage grows with time
Snapshots can be used for optimization

Event Sourcing
Applications
Database systems
Datomic
EventStore

Naked Objects
Domain objects contain all business logic
User interface = Direct representation of domain
objects
It can be automatically generated
Automatic generation of:
User interfaces
REST APIs
Domain
Object
Domain
Object
Domain
Object
persistence
services
remoting
UI
REST

Naked Objects
Advantages
Adaptability to domain
Maintenance
Challenges
It may be difficult to adapt interface to special cases
Applications
Naked Objects (.Net), Apache Isis (Java)

Software Architecture Taxonomies - modularity

Recommended

More Related Content

What's hot (20)

Similar to Software Architecture Taxonomies - modularity (20)

More from Jose Emilio Labra Gayo (20)

Recently uploaded (20)

Software Architecture Taxonomies - modularity