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.

(Note; this is suggested a 90 minute presentation however it can be extended to a full half-day, one day or two day workshop. I also have two other agile presentations which I can submit if interest is there - these cover agile planning).

1 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/Structure of the Talk

* introduction and overview.

* overview of the five strata

* each strata in detail

* a simple application (dvd store) worked example demonstrating the strata ina practical sense

* summary and q&a

Learning Outcome

At the end of the session delegages will:

* understand the five strata presented and which (e.g. Java, Ruby) software packages in an application live in which strata

* understand how using the agile architecture presented eases change.

* understand the  basics of designing and or refactoring using the strata.

Target Audience

software architects and designers who want their software to be easy to change

schedule Submitted 6 years ago

Public Feedback

comment Suggest improvements to the Speaker
  • Deepak Dhananjaya
    By Deepak Dhananjaya  ~  3 years ago
    reply Reply

    Hi Mark,

     Definitely a attractive presentation :) I would also invite you to think about Sharing some of the challenges team may have in using this approaches (if there are any!). So that they could forsee it and still work it thru! 


  • Sachin goel
    By Sachin goel  ~  6 years ago
    reply Reply

    Hi Mark,

    Curious to know whats the Agile Connection here, some i see linked with refactoring. The object oriented concepts and layered arch seem to exist before agile as well. These will still be relevant for an age old waterfall method as well?

    Will help if you can update the proposal to bring alignment with theme of the confernece.



    • Mark Collins-Cope
      By Mark Collins-Cope  ~  6 years ago
      reply Reply

      Hi Sachin,

      Thanks for your feedback.

      First of all some background: this presentation was given at the first ever XP conference in 2000 in Italy - and is published in the book XP Examined.

      However to address your main point - what has this to do with agility - is fairly simple.

      If you're undertaking any agile process - XP, Scrum, whatever, you will be evolving your software incrementally every release - adding new functionality - be that every week, two weeks or every month.

      This means that you will be faced with having to refactor your code on a very regular basis - which in turn means that software architecture and design are even more important than on a waterfall process. If you get the gross architecture wrong then you will find it becomes more and more difficult to refactor your code.

      If this happens you will cease to be agile at all. If you can't change your code quickly you can't adapt to changing business requirements at the necessary speed. This means that your velocity will decrease more and more every increment - and that is the death knell for an agile project. It is hard to underestimate how important this is.

      As it turns out, there are some key architectural principles that underpin good flexible software design - and this talk discusses them in some detail with a particular reference to agile development and changing requirements. 

      These include (briefly, but not completely): 

      * Seperation of the concerns of interfacing (to the outside world, be it a person or another computer system); of domain (the business specific elements of the application - those which will change as requirements will change) and of technical infrastructure (which should hopefully be fairly stable under changing business requirements).

      Rapid development and refactoring require that these concerns are well seperated in order to minimise the impact of any particular change as much as possible - to make it as easy to acheive as possible. This will be explained fully in the talk/workshop.

      * Dependency management. Which pieces of your software should dependent on which other pieces? Building on the Stable Dependencies Principle and the Stable Abstractions Principle - it is important to get the dependencies between your packages going in the right direction - downwards in terms of the model presented - and in particular to ensure that the more stable elements (packages) are depended on by the less stable elements (packages, modules...) - not the other way round. Unfortunately this happens far too often.

      The impact of dependencies being incorrectly managed is again a drastic lowering of velocity - and the consequent inability to respond to changing requirements. If the packages that are depended on are unstable in the face of changing business requirements - the impact of any particular change will propogate all the way up the dependency chain - meaning a lot more code has to be changed to implement a new or changed requirement.

      * Classification of types of change. It also turns out that types of requirements change can be classified in terms of the strata presented in the model. Very briefly there are superficial interface changes, deeper business rule and domain changes, and deepest of all: non-functional requirements changes (e.g. scale from single user to multi-user) - this classification is reflected in the model presented.

      * Finally TDD. As you're no doubt aware, if you don't have automated tests it can be very difficult to refactor without screwing up what already works. Automated tests provide a safeguard against this. 

      The final point of the model is that it suggests two major points (and a couple of minor ones) against which automated testing should be used (API boundaries - if you like). These are: the interface/domain boundary and the domain/infrastucture boundary. The former provides a basis on which the system may be tested at a functional (business) level. The latter provides a clear point for testing the underlying technical infrastructure of the project.

      (there is more to TDD than this - of course - but the model does give some pointers).

      So as a whole the model presented will enhance agility - one aspect of which is the ability to respond quickly to changing requirements - by easing the cost of changing existing software (or refactoring as it is known :-).

      Please let me know if this answers your query. I'll update the synopsis accordingly but I'm interested in your further feedback.

      (please note: the slides shown are not the slides that will eventually be used - I'm updating them at present).

      All the best,


      (BTW: in case whoever runs this website is watching - it is absolutely terrible - which doesn't look too good for a software developement related conference - does it?

      I've had to retype stuff two or three times (being told I have to log in when I am logged in), the visuals don't work properly in Google chrome, and it is not very easy to navigate!)

      Perhaps you could add a bug reporting system to the site?

      • Naresh Jain
        By Naresh Jain  ~  6 years ago
        reply Reply

        Mark, thanks for your feedback about the website. Let me try and answer each of your concerns one by one.

        1. Session Time-Outs - We had made a wrong assumption that people have ready-to-go proposals and they just paste the relevants parts into the form and submit it. Hence we has left the default PHP session timeout of 24 mins. This problem has been fixed since. Now the default session timeout is 1 week. What you were seeing on the top right corner was read-only info stored on the client side in a cookiee. On the server side your session might have expired, but the cookiee would continue to show your read-only info. We realized this is also confusing people. We've changed this as well.
        2. Bug Tracking: May be you missed the organe Feedback button on the bottom right corner of every page. Please use that to file your bug reports. So far every issue we've recieved we've fixed it.
        3. Visuals: We've tested the system in various OS+Brwoser combinations. But we might have missed a specific combination. If you can file a bug with your OS & browser version info along with a screenshot, it would really help us fix the issue.
        4. Navigaton: Would greatly appreciate if you can suggest how we can improve the navigation.

        Thanks again for your feedback and hope to get some good suggestions from your side to make this site better.