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.

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

21. agile architecture
21 - architecture to ease refactoring under changing requirements
video stores - implementation modelvideo stores - implementation model
cd VideoStoreImplementationDiagram
ff
InterfaceAlertControl
AlertTimer
PlatformTimer
GeneralTimerUtility
DomainCustomers
DomainAlertsDomainVideos
DomainReservations
Customers
Customer
Alerts
Alert
Reservations
Reservation
Videos
Video
ApplicationAlertServices
AlertServices
«interface»
AlertSender
EmailAlertSender
InfrastructurePersistence
Key
Transaction
InfrastructureSMS
SMSListener
«interface»
SMSActioner
SMSSender
SMSAlertSender
InterfaceIncomingSMS
SMSParser
ApplicationReservationServices
ReservationServices
InterfaceReservationGUI
PlatformGUILibrary
SimpleButton
ReserveVideoButton
PlatformJDBC
PlatformEmail
Emailer
ApplicationCustomerServices
CustomerServices
ApplicationVideoServices
VideoServices
... etc
ReserveVideoDialog
*
*
*
**
*
*
*
«realize»
«realize»
«realize»
common pattern:
platform/infrastructure
calls-back to interface
- timer
- UI
- SMS Listener
decoupled domain-layer
packages
in-house written SMS
package
in-house persistence

22. agile architecture
22 - architecture to ease refactoring under changing requirements
video stores - typical interactionvideo stores - typical interaction
cd SMSParser in action
InterfaceIncomingSMS
SMSParser
+ processIncomingSMS(text, telNumber) : void
InfrastructureSMS
SMSListener
+ SMSListener() : void
«interface»
SMSActioner
+ processIncomingSMS(telNumber, text) : void
ApplicationReservationServices
ReservationServices
+ ReserveVideoForCustomer(v, c) : void
ApplicationCustomerServices
CustomerServices
+ FindCustomerByTelNumber() : Key
DomainCustomers
Customer
+ Customer(telNumber) : void
[2.1] Find the customer by tel. no. [3] Make reservation
«realize»
[1] Call back invokes SMSParser
[2.2]

23. agile architecture
23 - architecture to ease refactoring under changing requirements
decoupling the domain by keydecoupling the domain by key
cd DomainReservations - in detail
DomainReservations
Reservation
- reserver: Key
- reservedItem: Key
+ Reservation(Key, Key) : void
Reservations
+ createReservation(Key, Key) : void
*
*

24. agile architecture
24 - architecture to ease refactoring under changing requirements
application versus domainapplication versus domain
application may “customise”
extensible domain packages
application / domain split
assists in automated testing –
next slide
improved code factoring –
two implementations of
AlertSender
cd VideoStoreImplementationDiagram
DomainAlerts
Alerts
Alert
ApplicationAlertServices
AlertServices
«interface»
AlertSender
EmailAlertSender
SMSAlertSender
*
*
«realize»
«realize»

25. agile architecture
25 - architecture to ease refactoring under changing requirements
automated unit testing (domain)automated unit testing (domain)
TestDomainAlerts
pretends to be an
application layer
package
MockAlerter
enabels
TestDomainAlerts
to verify the
correct behaviour
cd AlertPackageAndTestHarness
DomainAlerts
Alert
- watcher: Key
- watchedItem: Key
Alerts
+ SendNecessaryAlerts() : void
+ createAlert() : void
«interface»
AlertSender
+ sendAlert(watchedItem, watcher) : void
TestDomainAlerts
DomainAlertTester
+ testDomainAlert() : void
MockAlerter
+ sendAlert(watchedItem, watcher) : void
«realize»
*
*

26. agile architecture
26 - architecture to ease refactoring under changing requirements
video stores - implementation modelvideo stores - implementation model
cd VideoStoreImplementationDiagram
ff
InterfaceAlertControl
AlertTimer
PlatformTimer
GeneralTimerUtility
DomainCustomers
DomainAlertsDomainVideos
DomainReservations
Customers
Customer
Alerts
Alert
Reservations
Reservation
Videos
Video
ApplicationAlertServices
AlertServices
«interface»
AlertSender
EmailAlertSender
InfrastructurePersistence
Key
Transaction
InfrastructureSMS
SMSListener
«interface»
SMSActioner
SMSSender
SMSAlertSender
InterfaceIncomingSMS
SMSParser
ApplicationReservationServices
ReservationServices
InterfaceReservationGUI
PlatformGUILibrary
SimpleButton
ReserveVideoButton
PlatformJDBC
PlatformEmail
Emailer
ApplicationCustomerServices
CustomerServices
ApplicationVideoServices
VideoServices
... etc
ReserveVideoDialog
*
*
*
**
*
*
*
«realize»
«realize»
«realize»
common pattern:
platform/infrastructure
calls-back to interface
- timer
- UI
- SMS Listener
decoupled domain-layer
packages
in-house written SMS
package
in-house persistence

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