agile architecture - two hour presentation - two worked examples
DESCRIPTION
This talk discusses a reference architecture for object-oriented/component based systems consisting of five strata (or layers**). The purpose of the talk is to show how this large-scale application model helps us to understand the overall structure of a system, how strata help us to clarify our thoughts, and how it encourages the separation of concerns such as the technical v. the problem domain, policy v. mechanism, and the buy-or-build decision - and of course why this style of architecture is relevant to ease of refactoring and software restructuring under changing and multiple requirement sets. Assuming an application is made up of a number of components, the strata proposed is based on how specific to the particular requirements of an application each component is. More specific (and therefore less reusable) components are placed in the higher layers, and the more general, reusable components are in the lower layers. Since general non-application components are less likely to change than application specific ones, this leads to a stable system as all dependencies are downward in the direction of stability, and so changes tend not to propagate across the system as a whole. ** regarding: layers As well as presenting the reference model, this talk also discusses and clarifies in concrete terms the meaning of one architectural layer being above another. Perhaps surprisingly, the meaning of the layering metaphor is the subject of some confusion. Specific examples of this are given in the talk - though not yet shown on the slides.TRANSCRIPT
agile architecture
1 - architecture to ease refactoring under changing requirements
an architectural reference model an 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-copeindependent consultantindependent consultant
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
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!
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!
agilityquality
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
agile architecture
6 - architecture to ease refactoring under changing requirements
arm - banking application examplearm - banking application example
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)
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
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)
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”
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
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
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
FileExchangeManager
DebitControl
DBTransactionManager
AccountDebitRuleChecker
AppDebitRules
PersistentClass
Class Component(<<component subsystem>>)
1-1 directedassociation
is a subclass of
*
GUIDialog Other platform services … (e.g. RBDMS)
GUI Environment -eg. Windows/Motif
Bespoke persistencecomponent
1-many directedassociation
*
Generic accountcomponent
Application specificuse of accountcomponent
... ...
... ...
Interaction with external world
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
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
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
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!
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
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 [email protected])
Or come and talk to me after the presentation!
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
agile architecture
21 - architecture to ease refactoring under changing requirements
video stores - implementation modelvideo stores - implementation modelcd VideoStoreImplementationDiagram
ff
InterfaceAlertControl
AlertTimer
PlatformTimer
GeneralTimerUtility
DomainCustomersDomainAlertsDomainVideos
DomainReserv ations
Customers
Customer
Alerts
Alert
Reserv ations
Reserv ation
Videos
Video
ApplicationAlertServ ices
AlertServ ices
«interface»AlertSender
EmailAlertSender
InfrastructurePersistence
Key
TransactionInfrastructureSMS
SMSListener
«interface»SMSActioner
SMSSender
SMSAlertSender
InterfaceIncomingSMS
SMSParser
ApplicationReserv ationServ ices
Reserv ationServ ices
InterfaceReserv ationGUI
PlatformGUILibrary
SimpleButton
Reserv eVideoButton
PlatformJDBC
PlatformEmail
Emailer
ApplicationCustomerServ ices
CustomerServ ices
ApplicationVideoServ ices
VideoServ ices
... etc
Reserv eVideoDialog
*
*
*
**
**
*
«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
agile architecture
22 - architecture to ease refactoring under changing requirements
video stores - typical interactionvideo stores - typical interactioncd SMSParser in action
InterfaceIncomingSMS
SMSParser
+ processIncomingSMS(text, telNumber) : void
InfrastructureSMS
SMSListener
+ SMSListener() : void
«interface»SMSActioner
+ processIncomingSMS(telNumber, text) : void
ApplicationReserv ationServ ices
Reserv ationServ ices
+ ReserveVideoForCustomer(v, c) : void
ApplicationCustomerServ ices
CustomerServ ices
+ 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]
agile architecture
23 - architecture to ease refactoring under changing requirements
decoupling the domain by keydecoupling the domain by keycd DomainReserv ations - in detail
DomainReserv ations
Reserv ation
- reserver: Key- reservedItem: Key
+ Reservation(Key, Key) : void
Reserv ations
+ createReservation(Key, Key) : void
*
*
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
ApplicationAlertServ ices
AlertServ ices
«interface»AlertSender
EmailAlertSender
SMSAlertSender
*
*
«realize»
«realize»
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»
**
agile architecture
26 - architecture to ease refactoring under changing requirements
video stores - implementation modelvideo stores - implementation modelcd VideoStoreImplementationDiagram
ff
InterfaceAlertControl
AlertTimer
PlatformTimer
GeneralTimerUtility
DomainCustomersDomainAlertsDomainVideos
DomainReserv ations
Customers
Customer
Alerts
Alert
Reserv ations
Reserv ation
Videos
Video
ApplicationAlertServ ices
AlertServ ices
«interface»AlertSender
EmailAlertSender
InfrastructurePersistence
Key
TransactionInfrastructureSMS
SMSListener
«interface»SMSActioner
SMSSender
SMSAlertSender
InterfaceIncomingSMS
SMSParser
ApplicationReserv ationServ ices
Reserv ationServ ices
InterfaceReserv ationGUI
PlatformGUILibrary
SimpleButton
Reserv eVideoButton
PlatformJDBC
PlatformEmail
Emailer
ApplicationCustomerServ ices
CustomerServ ices
ApplicationVideoServ ices
VideoServ ices
... etc
Reserv eVideoDialog
*
*
*
**
**
*
«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
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?
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