Upload
jose-emilio-labra-gayo
View
312
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Software Architecture Taxonomies - modularity Jose Emilio Labra Gayo Software Architecture Course
Citation preview
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Software ArchitecturePart II. Architecture classifications3 - Modularity
Jose Emilio Labra Gayo
2014
ESEspañol
Universidad de Oviedo
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Modularity
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Modularity StylesBig Ball of MudHierarchical decompositionDependenciesGeneralizationLayersAspect Oriented decompositionDomain based decomposition
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Big Ball of Mud
Big Ball of MudDescribed by Foote & Yoder, 1997
ElementsLots of entities intertwined
ConstraintsNone
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Big Ball of Mud
AdvantagesQuick-start
It is possible to start without defining an architecture
Solve problems on demandCheap solution for short-term projects
It can be OK for some projects
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Big Ball of Mud
ProblemsHigh Maintenance costsLow flexibility from a given point
At start it can be very flexibleAfter some time, a change can be dramatic
InertiaWhen the system becomes a Big Ball of Mud it
is very difficult to convert it to another thingA few prestigious developers know where to
touchClean developers run away from these systems
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Big Ball of Mud
Some reasonsThrowaway code:
You need an immediate fix for a small problem, a quick prototype or proof of concept
When it is good enough, you ship itPiecemeal growthCut/Paste reuse
Bad code is reproduced in lots of placesAnti-patternsBad smells
Code/Architecture
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Modular decomposition
ElementsModules
Each module has an interface and a bodyRelationships "is part of" between modules
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Modular decomposition
DefinitionsModule:
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 moduleHow to use it Contract
BodyHow it is implemented
Interface
Body(Implementation)
Module
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Modular decompositionQuality attributes
CommnicationCommunicates the general aspect of the
systemMinimizes complexity
A module only exposes an interfaceExtensibility, maintenance
Facilitates changes and extensionsLocalized functionality
ReusabilityModules can be used in other contextsProduct lines
IndependenceModules can be developed by different teams
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Modular decomposition
ChallengesBad decomposition can augment complexityDecission: Develop vs buy
COTS modulesDependency management
Third parties modules can affect evolutionTeam organization
Modular decomposition can affect team development and organization
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Modular decomposition
ConstraintsNo cycles are allowedA module can only have one parent
System
Subsystem A
SubsystemB
SubsystemB1
SubsystemB2
Subsystem A2
SubsystemA1
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Modular decomposition
Some recommendationsHigh cohesionLow couplingSOLID principlesDemeter's LawFluid interfaces
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Modularity recommendations
High cohesionCohesion = Coherence of a module
Each module must solve one functionalityDRY (Don't Repeat Yourself) Principle
Intention must be declared in only one placeIt should be possible to test each module
separately
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Modularity recommendations
Low couplingCoupling = Interaction degree between
modulesLow coupling Improves modifiabilityIndependent deployment of each moduleStability against changes in other modules
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Modularity recommendations
SOLID principlesThey 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)
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
(S)ingle Responsibility
A module must have one responsibilityResponsibility = A reason to changeNo more than one reason to change a module
Otherwise, responsibilities are mixed and coupling increases
vs
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
(S)ingle Resposibility
http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
class Employee { def calculatePay(): Money = { ??? }
def saveDB() { ??? }
def reportWorkingHours(): String = { ??? }
}
Financial department
Operations
Management
Responsible departments
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.
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
(O)pen/Closed principle
Open for extensionThe module must adapt to new changesChange/adapt the behavior of a module
Closed for modificationChanges 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
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
(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
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
(L)iskov Substitution
Subtypes must follow supertypes contractA type B is a subtype of A when:xA, if there is a property Q such that Q(x) then yB, Q(y)
"Derived types must be completely substitutable by their base types"
Common mistakes:Inherit and modify behaviour of base classAdd functionality to supertypes that subtypes don't follow
A
B
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
(L)iskov Substitution
Duck
haceCuaktieneFormaPatorespira)
RubberDuckyDuckInPark
doCuakhasShapeDuckbreathes)
X
Example
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
(I)nterface Segregation
Clients must not depend on unused methodsBetter to have small and cohesive interfacesOtherwise non desired dependencies
If a module depends on non-used functionalities and these functionalities change, the module can be effected
ClientA
ClientB
InterfaceA
methodA1
methodA2InterfaceB
methodB1
methodB2
Service
mehtodA1methodA2methodB1methodB2
...
<<uses>>
<<uses>>
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
(D)ependency Inversion
Invert conventional dependencies High-level modules should not depend on low-level
modulesBoth 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.pdfhttp://martinfowler.com/articles/dipInTheWild.html
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
(D)ependency Inversion
Lowers couplingFacilitates unit testing
Substituting low level modules by test doublesRelated with:
Dependency injection and Inversion of ControlFrameworks: Spring, Guice, etc.
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Demeter's Law
Principle of less knowledgeModules only communicates with near
modulesGoal: low coupling
Lower number of invoked methodsTradeoff solution
It is not always possitiveIt can augment number of methods in modules
Symptoms of bad design:Using more than one dot...a.b.method(...)
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Fluent APIs
Improve readability and usability of interfacesAdvantages
Can lead to domain specific languagesAuto-complete facilities by IDEs
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Fluent APIs
Methods that modify return the same object
Several methods can be chainedExample:
Product p = new Product(). setName("Pepe"). setPrice(23);
It does not contradict Demeter's Law because it acts on the same object
class Product { ... public Product setPrice(double price) { this.price = price; return this; };
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Other modularity recommendationsFacilitate external configuration of a
moduleCreate an external configuration module
Create a default implementationGRASP Principles
General Responsibility Assignment Software Patterns
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Module SystemsIn Java:
OSGi Module = bundleControls encapsulationIt allows to install, start, stop and deinstall
modules during runtimeUsed in EclipseModules = Micro-servicesSeveral implementations: Apache Felix,
EquinoxJigsaw Project (Java 9)
In .Net: Assemblies
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Module Dependencies
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Module Dependencies
Relationship "uses"One module uses (depends on) other
module
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Module Dependencies
ElementesModulesRelationships "depends on" between
modulesConstraints
Module M1 depends on M2 if correct behavior of M1 depends on correct behavior of M2
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Module Dependencies
Advantages:Incremental development
Implement part of the functionalityDebugging, testingFacilitates impact analysis upon changes
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Module dependencies
ChallengesDependency management
Avoid cyclic dependenciesModules that depend on a lot of modules
Limits incremental development
Bad separation of concerns
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Generalization/Specialization
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Generalization/specialization
ElementsModulesRelationships (is-a) between
modulesConstraints:
Parent is more general than children
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Generalization/Specialization
AdvantagesFacilitates extensión and architecture
evolutionNotion of inheritance in OO designCaptures common parts with variations =
childrenChange and local variation
Reuse
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Generalization/Specialization
ChallengesComplexity to identify relationshipsExceptionsMultiple inheritance implications
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Generalization/Specialization
ApplicationsApplication frameworks
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Layers
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Layers
Divide software modules in layersOrder between layersEach layer exposes an interface that can be
used by higher layers
Layer N
Layer N - 1
. . .
Layer 1
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Layers
ElementsLayer: set of functionalities exposed through
an interface at a level NOrder relationship between layers
Layer N
Layer N - 1
. . .
Layer 1
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Capas
ConstraintsEach software block belongs to one layerThere are at least 2 layersA layer can be:
Client: consumes services from below layersServer: provides services to upper layers
2 variants:Strict: Layer N uses only functionality from
layer N-1Lax: Layer N uses functionalities from layers 1
to N - 1No cycles
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Layers
Example
User interface
Application
Domain
Infrastructure
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Layers
Layers ≠ ModulesA 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
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Layers
Layer: conceptual separation Tier: physical separation
Presentation
Data
Business
3-Layers
ExternalApplications
Legacy systems
Database
Businesslogic
Firewall
Thin client
RIA
3-tiers
Presentation Business Data
Layers ≠ Tiers
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Layers
AdvantagesSeparates different abstraction levelsLoose coupling: independent evolution of
each layerIt is possible to offer different implementations
of a layer that keep the same interfaceReusability
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
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Layers
ChallengesIt is notalways possible to apply it
Not always do we have different abstraction levels
PerformanceAccess through layers can slow the system
ShortcutsSometimes, it may be necessary to skip some
layers
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Layers
Example: Android
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Layers
Variants: Virtual machines, APIs3-layers, N-layers
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Virtual machine
Virtual machine = Opaque layerHides a specific OS implementation
One can only get Access through the public API
Program
Virtual Machine
API
Operating System
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Virtual machines
AdvantagesPortabilitySimplifies software development
Higher-level programmingFacilitates emulation
ChallengesPerformance
JIT techniquesComputational overload generated by the
new layer
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Virtual machine
ApplicationsProgramming languages
JVM: Java Virtual MachineCLR .Net
Emulation software
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
3-layers (N-layers)
Conceptual decompositionPresentationBusiness logicData
Presentation
Data
Business
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Aspect Oriented
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Aspect Oriented
Aspects: Modules that implement crosscutting features
Presentation
Data
Business
Secu
rity
Mon
itori
zati
on
Log
gin
g
AspectsIn
tern
tion
ali
zati
on
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
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
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Aspect OrientedExample: Book flight seats
Several methods to do the booking:Book a seatBook a rowBook 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...
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Aspect OrientedTraditional solutionclass 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
LoggingSecurity
Transaction
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Aspect Oriented
Structure
Core Application
Logic
Crosscutting
concern
Crosscutting
concern
Crosscutting
concern(aspect)
Aspect compiler (weaving)
Final application
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Aspect Oriented
DefinitionsJoin point: Point where an
aspect can be insertedAspect:
Contains:Advice: defines the job of the
aspectPointcut: where the aspect will
be introducedIt can match one or more join
points
Pointcut
RunningProgram
Join points
Advice
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Aspect Oriented
Aspect example in @Aspectj
@Aspectpublic 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
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Aspect Oriented
Constraints:An aspect can affect one or more traditional
modulesAn aspect captures all the definitions of a
crosscutting-concernThe aspect must be inserted in the code
Tools for automatic introduction
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Aspect Oriented
AdvantagesSimpler design
Basic application is clean of crosscutting concerns
Facilitates system modifiability and maintenanceCrosscutting concerns are localized in a single
moduleReuse
Crosscutting concerns can be reused in other systems
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Aspect Oriented
ChallengesExternal tools are needed
Aspects compiler. Example: AspectJOther tools: Spring, JBoss
Debugging is more complexA bug in one aspect module can have unknown
consequences in other modulesProgram flow is more complex
Team development needs new skillsNot every developer knows aspect oriented
programming
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Aspect Oriented
ApplicationsAspectJ = Java extension with AOPGuice = Dependency injection FrameworkSpring = Enterprise framework with
dependency injection and AOPVariants
DCI (Data-Context-Interaction): It is centered in the identification of roles from use cases
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Domain basedDomain based
Domain driven designHexagonal architectureData centeredPatterns
CQRSEvent sourcingNaked Objects
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Data model vs domain model
Data modelsPhysical: Data representation
Tables, columns, keys, ...
Logical: Data structure
Entities and relationships
Domain modelsConceptual model of a
domain Vocabulary and context
Entities, relationshipsBehavior
Business rules
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Domain based
Centered on the domain and the business logicGoal: Anticipate and handle changes in
domainCollaboration between developers and
domain experts
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Domain based
ElementsDomain model: formed by:
ContextEntitiesRelationships
ApplicationManipulates domain elements
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Domain based
ConstraintsDomain model is a clearly identified module
separated from other modulesDomain centered application
Application must adapt to domain model changes
No topological constraints
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Domain based
Advantages:Facilitates team communication
Ubiquitous languageReflects domain structure
Address domain changesShare and reuse models
Reinforce data quality and consistencyFacilitates system testing
It is possible to create testing doubles with fake domain data
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Domain basedChallenges:
Collaboration with domain expertsStalled analysis phase
It is necessary to establish context boundariesTechnological dependency
Avoid domain models that depend on some specific persistence technologies
SynchronizationSynchronize system with domain changes
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Domain basedVariants
DDD - Domain driven designHexagonal styleData centeredN-Layered Domain Driven DesignRelated patterns:
CQRS (Command Query Responsibility Segregation)
Event SourcingNaked Objects
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
DDD - Domain Driven Design
General approach to software developmentProposed by Eric Evans (2004)Connect the implementation to an evolving
domainCollaboration between technical and domain
experts Ubiquitous language
Common vocabulary shared by the experts and the development team
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
DDD - Domain Driven Design
ElementsBounded context
Specifies the boundaries of the domainEntities
An object with an identityValue objects
Contain attributes but no identityAggregates
Collection of objects bound together by some root entity
ServicesExternal operations
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
DDD - Domain Driven Design
ConstraintsEntities inside aggregates are only
accessible through the root entityValue objects contain only attributes
(immutables)
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
DDD - Domain driven design
AdvantagesCode organization
Identification of the main partsMaintenance/evolution of the system
Facilitates refactoringIt adapts to Behaviour Driven Development
Team communication
Problem spaceDomain experts
Solution spaceDevelopment team
Ubiquitous language
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
DDD - Domain driven design
ChallengesInvolve domain experts in development
It is not always possibleApparent complexity
It adds some constraints to developmentUseful for complex, non-trivial domains
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Hexagonal styleOther names:
ports and adapters, onion, clean, etc.Based on a clean Domain model
Infrastructures and frameworks are outsideAccess through ports and adapters
ApplicationAdapter
Adapter
Adapter
Adapter
Adapter
Domainmodel
http://alistair.cockburn.us/Hexagonal+architecturehttp://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
port
port
port
Adapter
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Hexagonal style
Example Traditional application in layers
Incorporates new servicesTesting DB
ApplicationAdapter
UI
DBMySQL
Adapter DB2
AdapterREST
Adapterprinter
Adapter DB1
External Applicati
on
DomainModelA
PI
port
data
port
DBMongoDB
logging port
AdapterDB testing
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Hexagonal style
ElementsDomain model
Represents business logic: Entities and relationships
Plain Objects (POJOs: Plain Old Java Objects)Ports
Communication interfaceIt can be: User, Database
AdaptersOne adapter by each external elementExamples: REST, User, DB SQL, DB mock,...
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Hexagonal style
AdvantagesUnderstanding
Improves domain understandingTimelessness
Less dependency on technologies and frameworksAdaptability (time to market)
It is easier to adapt the application to changes in the domain
TestabilityIt is possible to substitute real databases by mock
databases
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Hexagonal style
ChallengesIt can be difficult to separate domain from
the persistence systemLots of frameworks combine both
Asymmetry of ports & adaptersNot all are equalActive ports (user) vs passive ports (logger)
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Data centered
Simple domains based on dataCRUD (Create-Retrieve-Update-Delete)
operationsAdvantages:
Semi-automatic generation (scaffolding)Rapid development (time-to-market)
ChallengesEvolution to more complex domainsAnemic domains
Classes that only contain getters/settersObjects 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/
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Domain based styles
3 patterns relatedCQRSEvent SourcingNaked Objects
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
CQRS
Command Query Responsibility SegregationSeparate models in 2 parts
Command: Does changes (updates information)Query: Only queries (get information)
Application
Model
UserInterfac
e
DataBase
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
CQRS
Command Query Responsibility SegregationSeparate models in 2 parts
Command: Does changes (updates information)Query: Only queries (get information)
Application
Query
UserInterfac
e
DataBase
Command
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
CQRS
AdvantagesScalability
Optimize queries (read-only)Asynchronous commands
Facilitates team decomposition and organization1 team for read access (queries)1 team for read/write access (command)
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
CQRS
ChallengesHybrid operations (both query and
command)Example: pop() in a stack
ComplexityFor simple CRUD applications it can be too
complexSynchronization
Possibility of queries over non-updated data
ApplicationsAxon Framework
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Event Sourcing
All changes to application state are stored as a sequence of eventsEvery change is captured in an event store
It is possible to trace and undo changes
Write
----------------------------------------------------------------------
Event store
EventDriver
Read
snapshots
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Event SourcingElements
Events: something that has happened, in the pastEvent store: Events are always added (append-
only)Event driver: handles the different eventsSnapshots of aggragated state (optional)
Write
----------------------------------------------------------------------
Event store
EventDriver
Read
snapshots
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Event Sourcing
AdvantagesFault toleranceTraceability
Determine the state of the application at any time
Rebuild and event-replayIt is possible to discard an application state
and re-run the events to rebuild a new stateScalability
Append-only DB can be optimized
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Event Sourcing
ChallengesEvent handling
Synchronization, consistencyComplexity of development
It addes a new indirection levelResource management
Event granularityEvent storage grows with time
Snapshots can be used for optimization
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Event Sourcing
ApplicationsDatabase systems
Datomic EventStore
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Naked Objects
Domain objects contain all business logicUser interface = Direct representation of
domain objectsIt can be automatically generated
Automatic generation of:User interfaces REST APIs
DomainObject
DomainObject
Domain
Object
persistence
services
REST
UI
remoting
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
Naked Objects
AdvantagesAdaptability to domainMaintenance
ChallengesIt may be difficult to adapt interface to
special casesApplications
Naked Objects (.Net), Apache Isis (Java)
Arquitectura del SoftwareE
scu
ela
de I
ngen
ierí
a I
nfo
rmáti
ca
Un
ivers
idad d
e
Ovi
edo
End of Presentation