agile architecture
1 - architecture to ease refactoring under changing requirements
an architectural reference modelan arc...
agile architecture
2 - architecture to ease refactoring under changing requirements
introducing the armintroducing the arm...
agile architecture
3 - architecture to ease refactoring under changing requirements
arm - where does it come fromarm - whe...
agile architecture
4 - architecture to ease refactoring under changing requirements
arm objectivesarm objectives
Factoring...
agile architecture
5 - architecture to ease refactoring under changing requirements
introducing the armintroducing the arm...
agile architecture
6 - architecture to ease refactoring under changing requirements
arm - banking application examplearm -...
agile architecture
7 - architecture to ease refactoring under changing requirements
interface - initiates!interface - init...
agile architecture
8 - architecture to ease refactoring under changing requirements
application - serves!application - ser...
agile architecture
9 - architecture to ease refactoring under changing requirements
domain - represents!domain - represent...
agile architecture
10 - architecture to ease refactoring under changing requirements
infrastructure - assists!infrastructu...
agile architecture
11 - architecture to ease refactoring under changing requirements
platform - underpins!platform - under...
agile architecture
12 - architecture to ease refactoring under changing requirements
introducing the armintroducing the ar...
agile architecture
13 - architecture to ease refactoring under changing requirements
arm - general rulesarm - general rule...
agile architecture
14 - architecture to ease refactoring under changing requirements
introducing the armintroducing the ar...
agile architecture
15 - architecture to ease refactoring under changing requirements
putting it into practiceputting it in...
agile architecture
16 - architecture to ease refactoring under changing requirements
putting it into practice – getting up...
agile architecture
17 - architecture to ease refactoring under changing requirements
putting it into practice – agile pack...
agile architecture
18 - architecture to ease refactoring under changing requirements
summarysummary
objectives and backgro...
agile architecture
19 - architecture to ease refactoring under changing requirements
any questions (end of part one)any qu...
agile architecture
20 - architecture to ease refactoring under changing requirements
part two – video stores examplepart t...
agile architecture
21 - architecture to ease refactoring under changing requirements
video stores - implementation modelvi...
agile architecture
22 - architecture to ease refactoring under changing requirements
video stores - typical interactionvid...
agile architecture
23 - architecture to ease refactoring under changing requirements
decoupling the domain by keydecouplin...
agile architecture
24 - architecture to ease refactoring under changing requirements
application versus domainapplication ...
agile architecture
25 - architecture to ease refactoring under changing requirements
automated unit testing (domain)automa...
agile architecture
26 - architecture to ease refactoring under changing requirements
video stores - implementation modelvi...
agile architecture
27 - architecture to ease refactoring under changing requirements
faqsfaqs
do I have to have all these ...
agile architecture
28 - architecture to ease refactoring under changing requirements
wrap-upwrap-up
ARM promotes:
Factorin...
Upcoming SlideShare
Loading in …5
×

agile architecture - two hour presentation - two worked examples

385 views
301 views

Published on

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.

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
385
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

agile architecture - two hour presentation - two worked examples

  1. 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. 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. 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. 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. 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. 6. agile architecture 6 - architecture to ease refactoring under changing requirements arm - banking application examplearm - banking application example
  7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×