The document describes an architectural reference model (ARM) for medium to large scale applications that need to undergo frequent changes. The ARM aims to ease refactoring under changing requirements by improving code factoring, separation of concerns, stability, and testability. It divides an application into layers including the interface layer, application layer, domain layer, infrastructure layer, and platform layer. The application layer provides a service-oriented architecture and acts as a coordinator. The domain layer represents domain abstractions and business logic. Examples are provided of how the ARM was implemented for banking and video rental applications.
How to Troubleshoot Apps for the Modern Connected Worker
agile architecture - two hour presentation - two worked examples
1. agile architecture
1 - architecture to ease refactoring under changing requirements
an architectural reference modelan architectural reference model
for medium to large scale applications that will undergo changefor medium to large scale applications that will undergo change
agile architectureagile architecture
mark collins-copemark collins-cope
independent consultantindependent consultant
2. agile architecture
2 - architecture to ease refactoring under changing requirements
introducing the armintroducing the arm
objectives and background
banking system worked example using arm
interface
application
domain
infrastructure
platform
arm rules
putting it into practice
summary
3. agile architecture
3 - architecture to ease refactoring under changing requirements
arm - where does it come fromarm - where does it come from
model we’ve developed and refined over many projects
has been “discovered” a number of times by different people
applied in current form on last four projects i’ve worked on
it works to reduce costs/timescales and increase quality!
4. agile architecture
4 - architecture to ease refactoring under changing requirements
arm objectivesarm objectives
Factoring - improved factoring of code
Intelligibility - knowing what is where
Separation of concerns - ui from core logic
from infrastructure
Stability - lower = more stable
Testabilility - improved test coverage
at the end of an ARM is a … FISST!
agility
quality
5. agile architecture
5 - architecture to ease refactoring under changing requirements
introducing the armintroducing the arm
objectives and background
banking system worked example using arm
interface
application
domain
infrastructure
platform
arm rules
putting it into practice
summary
6. agile architecture
6 - architecture to ease refactoring under changing requirements
arm - banking application examplearm - banking application example
7. agile architecture
7 - architecture to ease refactoring under changing requirements
interface - initiates!interface - initiates!
handles interface
to async. external
actors (seperation of concerns)
concerned with
presentation (UI or
XSI) (seperation of concerns)
timed behaviour
(factoring of code)
no business logic
(seperation of concerns)
uses SOA provided
by application
(factoring of code)
8. agile architecture
8 - architecture to ease refactoring under changing requirements
application - serves!application - serves!
service oriented
architecture (factoring of code)
createAccount
getAccounts
wiring together
domain layer
packages
application specific
customisations of
lower “outerfaces”
testability
soa enables automated
functional testing
9. agile architecture
9 - architecture to ease refactoring under changing requirements
domain - represents!domain - represents! domain specific
components
(factoring of code)
e.g. accounting, banking,
healthcare, etc.
potentially used across
multiple applications
(“product-line”
components)
often decoupled
(separation of concerns)
more stable than
application
(stability)
may have
“outerfaces”
(interfaces intended to be realised
by a higher layer)
tested via mock
application layer
(testability)
10. agile architecture
10 - architecture to ease refactoring under changing requirements
infrastructure - assists!infrastructure - assists!
no domain
dependencies
(stability)
re-usable technical
domain
components
(factoring of code / testability)
e.g. persistence, lists,
useful types, smart-
pointers, general
observer mechanism
(c++), etc.
very often have
“outerfaces”
11. agile architecture
11 - architecture to ease refactoring under changing requirements
platform - underpins!platform - underpins!
things you bring in!:
DBMS
STL (C++)
JDBC (Java)
Motif (Unix) Libs
Java Swing Libs
O/S APIs
clearly can’t depend
on your code!
infrastructure
components migrate to
platform over time
12. agile architecture
12 - architecture to ease refactoring under changing requirements
introducing the armintroducing the arm
objectives and background
banking system worked example using arm
interface
application
domain
infrastructure
platform
arm rules
putting it into practice
summary
13. agile architecture
13 - architecture to ease refactoring under changing requirements
arm - general rulesarm - general rules
dependencies point
downward
level of
component/package is
highest level of its
constituent classes
objective: push code down as
far as possible (stability)
e.g. ui validation in performed
in domain layer
e.g. general purpose SOA login
& security mechanism in
infrastructure
components/packages
shouldn’t cross layers -
split them (separation of
concerns)
GUIDebit
DialogBox
clerk central banking system
FileExchange
Manager
DebitControl
DBTransaction
Manager
Account
DebitRule
Checker
AppDebit
Rules
Persistent
Class
Class
Component
(<<component subsystem>>)
1-1 directed
association
is a subclass of
*
GUIDialog Other platform services … (e.g. RBDMS)
GUI Environment -
eg. Windows/Motif
Bespoke persistence
component
1-many directed
association
*
Generic account
component
Application specific
use of account
component
... ...
... ...
Interaction with external world
14. agile architecture
14 - architecture to ease refactoring under changing requirements
introducing the armintroducing the arm
objectives and background
banking system worked example using arm
interface
application
domain
infrastructure
platform
arm rules
putting it into practice
summary
15. agile architecture
15 - architecture to ease refactoring under changing requirements
putting it into practiceputting it into practice
arm in practise
Four projects (two in finance, one in AI, one in online content
provision)
practical experience - benefits – better quality less cost
common vocabulary between developers
reduced line count in code (intra-project re-use)
increased productivity (66% less time in one case)
costs – getting up to steam
16. agile architecture
16 - architecture to ease refactoring under changing requirements
putting it into practice – getting up to steamputting it into practice – getting up to steam
fragrance of the model presented here:
there are subtleties
these will become apparent when you try to use it
but:
it’s not rocket science
any reasonable developer can get to grips with it given
a couple of days training
some on project mentoring
17. agile architecture
17 - architecture to ease refactoring under changing requirements
putting it into practice – agile package mapputting it into practice – agile package map
MORE HOLIDAY PHOTOS LATER!
18. agile architecture
18 - architecture to ease refactoring under changing requirements
summarysummary
objectives and background
banking system worked example using arm
interface
application
domain
infrastructure
platform
arm rules
putting it into practice
summary
19. agile architecture
19 - architecture to ease refactoring under changing requirements
any questions (end of part one)any questions (end of part one)
For more information on the arm visit:
Markcollinscope.info -
development whitepapers
Two day course – agile architecture
(email markcollinscope@gmail.com)
Or come and talk to me after the
presentation!
20. agile architecture
20 - architecture to ease refactoring under changing requirements
part two – video stores examplepart two – video stores example
customers can register for email and text message alerts when a video comes
free
customers can reserve a video using the UI
customers can reserve a video by replying to text (SMS) message
TITLE CUSTOMER
search search
Cancel Reserve
27. agile architecture
27 - architecture to ease refactoring under changing requirements
faqsfaqs
do I have to have all these layers?
is this big up-front design?
shouldn’t it be a strictly layered model?
does using the arm lead to unnecessary extra code?
is persistence always infrastructure?
arm only deals with horizontal sub-division, doesn’t it?
does interface really initiate?
28. agile architecture
28 - architecture to ease refactoring under changing requirements
wrap-upwrap-up
ARM promotes:
Factoring of code
Intelligibility
Separation of concerns
Stability
Testability
ARM layers:
interface – initiates
activity
application – serves via
an SOA
domain – represents
domain abstractions
infrastructrure – assists
with non-domain
specific code
platform – underpins
