Design and Architecture in Industry  The agile viewpoint Ben Stopford Thoughtworks
What I’ll be covering <ul><li>The importance of expecting designs to change. </li></ul><ul><li>The softer side of architec...
Why do we need to worry about Architecture and Design? <ul><li>Software evolves over time. </li></ul><ul><li>Unmanaged cha...
So how to we avoid this?
We Architect our System
…  with UML
AND… We get to spot problems early on in the project lifecycle.  Why is that advantageous?
Because it costs less Low cost of change early in lifecycle
So we have a plan for how to build our application before we start coding.  All we need to do is follow the plan!!
Well this is what we used to do… … but problems kept cropping up…
It was really hard to get the design right up front. <ul><li>The problems we face are hard.  </li></ul><ul><li>The human b...
<ul><li>And then… </li></ul><ul><li>… when we did get the design right…  </li></ul><ul><li>… the users would go and change...
Ahhh, those pesky users, why can’t they make up their minds?
So… …in summary…
We find designing up front hard…
...and a bit bureaucratic
… and when we do get it right the users generally go and change the requirements…
… and it all changes in the next release anyway.
So are we taking the right approach
Software is supposed to be soft. That means it is supposed to be easy to change.
But is it? <ul><li>Small application are easy to change. </li></ul><ul><li>Large applications generally are not. </li></ul>
So is fixing the architecture and design up front the right way to do it?
Does the cost curve have to look like this?
Can we design our systems so that we CAN change them later in the lifecycle?
The Cost of Change in an agile application
How
By architecting and designing for change ** But not designing for any specific changes  *** And writing lots and lots of t...
Agile Development facilitates this Code Base Test Test Test
Dynamic Design <ul><li>Similar to up-front design except that it is done little and often. </li></ul><ul><li>Design just e...
This means that your system’s design is constantly evolving.
Making our key values: <ul><li>Changeability – because most software projects involve change.  </li></ul><ul><li>Comprehen...
So what does this imply for the Architect?
Architecture becomes about steering the application so that it remains easy to understand and easy to change.
With everyone being responsible for the design.
So the architects role becomes about steering the applications design through others.
Shepherding the team!
Shepherding the team <ul><li>People will always develop software in their own way. You can’t change this. </li></ul><ul><l...
Timeline Set-up Architecture Push patterns and reuse Watch for architectural breakers Amend Architecture
<ul><ul><li>Aims: </li></ul></ul><ul><ul><li>Encourage preferred patterns. </li></ul></ul><ul><ul><li>Encourage reuse. </l...
1. Architecture through reuse <ul><li>Good OO Design </li></ul><ul><li>Common Libraries </li></ul><ul><li>A Domain Model <...
The importance of a Domain Model <ul><li>Simulate the business problem in software. </li></ul><ul><li>Separate from any te...
2. Architecture through patterns
Separation of Concerns: Layers and Services
Example GUI Data Access <ul><li>Scaling such a solution is problematic? </li></ul><ul><li>Untangling the database code fro...
Model-View-Controller
A Real SOA and Layered System Rightmove.com
Business Services Communicating Asynchronously over a Bus Persistence of Hips Client Contacting Service - Services can onl...
SOA <ul><li>Architectural Pattern (Functional) </li></ul><ul><li>Design Pattern (Technical) </li></ul>
SOA as an A rchitectural Pattern <ul><li>Provides separation between the implementations of different business services gi...
SOA as a  Design Pattern <ul><li>Encourages separation of responsibilities into the different services. </li></ul><ul><li>...
So how does SOA compare to a Component Based Model <ul><li>CBS using Corba is very similar: </li></ul><ul><ul><li>Breakdow...
Layers and Tiers
<ul><li>Layers/Tiers  provide a pattern that promotes separation between  technical responsibilities . </li></ul><ul><li>S...
Layers vs. Services <ul><li>Services are generally wrapped behind well defined and controlled interfaces. </li></ul><ul><l...
Aside – Bob’s Website Client Application Layer DB Javascipt  Calculation Which way is best?? Client Application Layer DB S...
Layered Architecture HIP UI HIP Service Message Bus Data Layer Transformation Layer Business Layer Application Layer Prese...
What is the point of having layers? Separation of Technical Concerns
Example: Is a transformation layer a good idea? Application Layer Transformation Layer Persistence Layer Database Domain O...
UI Layer Application Layer Technical Decomposition into layering Trade Service Data Service Pricing Service Functional Dec...
Questions <ul><li>Is reuse across layers and services a good idea or does it break the encapsulation of those services or ...
3. Use of  frameworks to enforce design principals
For Example <ul><li>Inversion of Control and Spring, Picocontainer </li></ul><ul><li>Functional separation with OO, CBS, S...
Aside: What is wrong with the singleton pattern?
It’s very hard to test applications when singletons are around  <ul><li>public void foo() </li></ul><ul><li>{ </li></ul><u...
Dependency Injection <ul><li>public void foo(X x, Y y, Z z) </li></ul><ul><li>{ </li></ul><ul><li>… </li></ul><ul><li>} </...
Spring <ul><li>Inversion of control/Dependency injection makes code easy to test. </li></ul><ul><li>Helps you organise you...
Config.xml – Define Dependencies <ul><li><bean id=&quot;CurrencySpreadRecordDAO&quot; class=&quot;com.dkib.gf.dao.Currency...
Spring performs construction <ul><li>public class MyMarketDataFacade implements MarketDataFacade { </li></ul><ul><li>… </l...
Look Up Service <ul><li>public class DataLayer { </li></ul><ul><li>private final ApplicationContext ctx; </li></ul><ul><li...
But… <ul><li>These frameworks are not silver bullets. They each have their own problems. </li></ul>
Avoiding Architectural Breakers Course grained decisions that are hard to refactor away from. For example embedding busine...
Summary So Far <ul><li>Software is soft so design is an evolving process not a prescribed one. </li></ul><ul><li>Architect...
How design can go wrong
The overuse of design patterns => Obtuse code
Fragile Base Class Problem <ul><li>Why does this occur? </li></ul>A B C
Solutions <ul><li>Favour composition over inheritance. </li></ul><ul><li>Superclasses should call subclasses not the other...
Service Duplication Problem UI Layer Application Layer Technical Decomposition into layering Trade Service Data Service Pr...
Command/Executor Problem
Solution  Be wary of functional decomposition and its tendency to push you away from reuse
In Conclusion <ul><li>Comprehensibility is the goal of design (followed by changeability). </li></ul><ul><li>An architects...
And finally… Never listen to an architect who does not write code.  Conversely if you are an architect, make sure you get ...
Upcoming SlideShare
Loading in …5
×

Architecting for Change: An Agile Approach

1,256 views

Published on

A presentation given on the Software Architecture course at the University of Brunel in 2007 regarding how we architect for change.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,256
On SlideShare
0
From Embeds
0
Number of Embeds
143
Actions
Shares
0
Downloads
33
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Your design is always tested Encapsulate different concerns so that changes can be independent of one another
  • The subtle point here is that you must direct the applications progress through others. This
  • (b) Is closer to the typical architect’s role.
  • In an agile team we use stand-ups as a good opportunity to establish vision. e.g. broad patterns such as layered separation or finer grained patterns/components such as a centralised workflow engine.
  • Services can only communicate over the bus. No Point to point communication (why)
  • Bob build’s a website that does some funky calculations. Bob asks Fred if he thinks embedding the funky calculations in javascript on the client is a good idea?
  • Mapper prevents the domain layer being coupled to persistence. Qu: what happens when you split
  • What is wrong with static fields? If a class fun
  • Because changes to the superclass can affect all subclasses This tends to arise when the superclass is not a clean abstraction. That is to say that it is not doing something common to all its children.
  • Architecting for Change: An Agile Approach

    1. 1. Design and Architecture in Industry The agile viewpoint Ben Stopford Thoughtworks
    2. 2. What I’ll be covering <ul><li>The importance of expecting designs to change. </li></ul><ul><li>The softer side of architecture needed to successfully guide a team. </li></ul><ul><li>Methods for guiding design using patterns and frameworks. </li></ul><ul><li>Problems that can occur with design. </li></ul>
    3. 3. Why do we need to worry about Architecture and Design? <ul><li>Software evolves over time. </li></ul><ul><li>Unmanaged change leads to spaghetti code bases where classes are highly coupled to one another. </li></ul><ul><li>This makes them brittle and difficult to understand </li></ul>
    4. 4. So how to we avoid this?
    5. 5. We Architect our System
    6. 6. … with UML
    7. 7. AND… We get to spot problems early on in the project lifecycle. Why is that advantageous?
    8. 8. Because it costs less Low cost of change early in lifecycle
    9. 9. So we have a plan for how to build our application before we start coding. All we need to do is follow the plan!!
    10. 10. Well this is what we used to do… … but problems kept cropping up…
    11. 11. It was really hard to get the design right up front. <ul><li>The problems we face are hard. </li></ul><ul><li>The human brain is bad at predicting all the implications of a complex solution up front. </li></ul><ul><li>When we came to implementing solutions, our perspective would inevitably change and so would our design. </li></ul>
    12. 12. <ul><li>And then… </li></ul><ul><li>… when we did get the design right… </li></ul><ul><li>… the users would go and change the requirements and we’d have to redesign our model. </li></ul>
    13. 13. Ahhh, those pesky users, why can’t they make up their minds?
    14. 14. So… …in summary…
    15. 15. We find designing up front hard…
    16. 16. ...and a bit bureaucratic
    17. 17. … and when we do get it right the users generally go and change the requirements…
    18. 18. … and it all changes in the next release anyway.
    19. 19. So are we taking the right approach
    20. 20. Software is supposed to be soft. That means it is supposed to be easy to change.
    21. 21. But is it? <ul><li>Small application are easy to change. </li></ul><ul><li>Large applications generally are not. </li></ul>
    22. 22. So is fixing the architecture and design up front the right way to do it?
    23. 23. Does the cost curve have to look like this?
    24. 24. Can we design our systems so that we CAN change them later in the lifecycle?
    25. 25. The Cost of Change in an agile application
    26. 26. How
    27. 27. By architecting and designing for change ** But not designing for any specific changes *** And writing lots and lots of tests
    28. 28. Agile Development facilitates this Code Base Test Test Test
    29. 29. Dynamic Design <ul><li>Similar to up-front design except that it is done little and often. </li></ul><ul><li>Design just enough to solve the problem we are facing now, and NO MORE. </li></ul><ul><li>Refactor it later when a more complex solution is needed. </li></ul>
    30. 30. This means that your system’s design is constantly evolving.
    31. 31. Making our key values: <ul><li>Changeability – because most software projects involve change. </li></ul><ul><li>Comprehensibility – because the easier it is to understand, the easier it is to change. </li></ul>
    32. 32. So what does this imply for the Architect?
    33. 33. Architecture becomes about steering the application so that it remains easy to understand and easy to change.
    34. 34. With everyone being responsible for the design.
    35. 35. So the architects role becomes about steering the applications design through others.
    36. 36. Shepherding the team!
    37. 37. Shepherding the team <ul><li>People will always develop software in their own way. You can’t change this. </li></ul><ul><li>You use the techniques you know to keep the team moving in the right direction. </li></ul><ul><li>Occasionally one will run of in some tangential direction and when you see this you move them back. </li></ul>
    38. 38. Timeline Set-up Architecture Push patterns and reuse Watch for architectural breakers Amend Architecture
    39. 39. <ul><ul><li>Aims: </li></ul></ul><ul><ul><li>Encourage preferred patterns. </li></ul></ul><ul><ul><li>Encourage reuse. </li></ul></ul><ul><ul><li>Tools: </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Frameworks </li></ul></ul>
    40. 40. 1. Architecture through reuse <ul><li>Good OO Design </li></ul><ul><li>Common Libraries </li></ul><ul><li>A Domain Model </li></ul>
    41. 41. The importance of a Domain Model <ul><li>Simulate the business problem in software. </li></ul><ul><li>Separate from any technically implied dependencies. </li></ul>
    42. 42. 2. Architecture through patterns
    43. 43. Separation of Concerns: Layers and Services
    44. 44. Example GUI Data Access <ul><li>Scaling such a solution is problematic? </li></ul><ul><li>Untangling the database code from the UI code makes each easier to understand. This might not matter for small applications but the effect is very noticeable as the application grows. </li></ul>
    45. 45. Model-View-Controller
    46. 46. A Real SOA and Layered System Rightmove.com
    47. 47. Business Services Communicating Asynchronously over a Bus Persistence of Hips Client Contacting Service - Services can only communicate over the bus. No Point to point communication (why). - Communication via neutral protocol
    48. 48. SOA <ul><li>Architectural Pattern (Functional) </li></ul><ul><li>Design Pattern (Technical) </li></ul>
    49. 49. SOA as an A rchitectural Pattern <ul><li>Provides separation between the implementations of different business services giving: </li></ul><ul><ul><li>Scalability </li></ul></ul><ul><ul><li>Fungibility </li></ul></ul>
    50. 50. SOA as a Design Pattern <ul><li>Encourages separation of responsibilities into the different services. </li></ul><ul><li>Forces communication between services to be at a business level => Promotes tight encapsulation. </li></ul><ul><li>Asynchronous communication promotes statelessness of services. </li></ul>
    51. 51. So how does SOA compare to a Component Based Model <ul><li>CBS using Corba is very similar: </li></ul><ul><ul><li>Breakdown into component services </li></ul></ul><ul><ul><li>Language neutral protocol </li></ul></ul><ul><li>The key differences are: </li></ul><ul><ul><li>Making services valid at a business level with the aim being to integrate across the enterprise (mapping tools can be used to ensure the services match the business model). </li></ul></ul><ul><ul><li>Communication only through business significant messages – this has interesting architectural implications. </li></ul></ul>
    52. 52. Layers and Tiers
    53. 53. <ul><li>Layers/Tiers provide a pattern that promotes separation between technical responsibilities . </li></ul><ul><li>Services provide a pattern that promotes separation between functions at a business level . </li></ul>
    54. 54. Layers vs. Services <ul><li>Services are generally wrapped behind well defined and controlled interfaces. </li></ul><ul><li>Conversely the separation between layers is generally logical. </li></ul>
    55. 55. Aside – Bob’s Website Client Application Layer DB Javascipt Calculation Which way is best?? Client Application Layer DB Server Calculation
    56. 56. Layered Architecture HIP UI HIP Service Message Bus Data Layer Transformation Layer Business Layer Application Layer Presentation Layer The presentation layer is for pixel-painting. All logic should be delegated elsewhere. The application layer is the glue between presentation and business. It is where MVC controllers live. Logic here is very light – simple field-level validation is as clever as it gets (e.g. “is it a date?”, “is it a number?”) The business layer is a simulation of the business problem. It has no dependencies on the UI or on other technologies. Most importantly, it is isolated from persistence! (Similar to the Service Layer in RM+) The transformation layer is the glue between business logic and non-UI technologies. It maps information between the business logic and some underlying tech. e.g. It maps HIPs into messages for the bus and into records for the database. The data layer is represented by infrastructural tech. The RDBMS, and code to connect to the WebMethods bus sit here. Web Pages Controllers Domain Model Technology Abstraction & Mapping Tech infrastructure HIP DB
    57. 57. What is the point of having layers? Separation of Technical Concerns
    58. 58. Example: Is a transformation layer a good idea? Application Layer Transformation Layer Persistence Layer Database Domain Object Table ORM Domain Object Record Object Table Mapper ORM
    59. 59. UI Layer Application Layer Technical Decomposition into layering Trade Service Data Service Pricing Service Functional Decomposition into Services Domain Model, Utilities etc Reuse across services and potentially layers Application separation and crosscutting
    60. 60. Questions <ul><li>Is reuse across layers and services a good idea or does it break the encapsulation of those services or layers? </li></ul><ul><li>What about if the services span multiple teams? </li></ul>
    61. 61. 3. Use of frameworks to enforce design principals
    62. 62. For Example <ul><li>Inversion of Control and Spring, Picocontainer </li></ul><ul><li>Functional separation with OO, CBS, SOA </li></ul><ul><li>Layering with Hibernate, IBatis, Webwork </li></ul>
    63. 63. Aside: What is wrong with the singleton pattern?
    64. 64. It’s very hard to test applications when singletons are around <ul><li>public void foo() </li></ul><ul><li>{ </li></ul><ul><li>x = Fred.getInstance().getX(); </li></ul><ul><li>… </li></ul><ul><li>y = George.getInstance().getY(); </li></ul><ul><li>… </li></ul><ul><li>z = Arthur.getInstance().getZ(); </li></ul><ul><li>} </li></ul>
    65. 65. Dependency Injection <ul><li>public void foo(X x, Y y, Z z) </li></ul><ul><li>{ </li></ul><ul><li>… </li></ul><ul><li>} </li></ul>
    66. 66. Spring <ul><li>Inversion of control/Dependency injection makes code easy to test. </li></ul><ul><li>Helps you organise your middle tier. </li></ul><ul><li>Get rid of (the static aspects of) singletons. </li></ul>
    67. 67. Config.xml – Define Dependencies <ul><li><bean id=&quot;CurrencySpreadRecordDAO&quot; class=&quot;com.dkib.gf.dao.CurrencySpreadRecordDAOImpl&quot;> </li></ul><ul><li><property name=&quot;sqlMapClient&quot; ref=&quot;sqlMapClient&quot;/> </li></ul><ul><li></bean> </li></ul><ul><li><bean id=&quot;MarketDataDao&quot; class=&quot;com.dkib.gf.dao.MyMarketDataFacade&quot;> </li></ul><ul><li><constructor-arg index=&quot;0&quot; ref=&quot;DrivenPairRecordDAO&quot;/> </li></ul><ul><li><constructor-arg index=&quot;1&quot; ref=&quot;VolSmileRecordDAO&quot;/> </li></ul><ul><li><constructor-arg index=&quot;2&quot; ref=&quot;SpotRateRecordDAO&quot;/> </li></ul><ul><li><constructor-arg index=&quot;3&quot; ref=&quot;VolSpreadRecordDAO&quot;/> </li></ul><ul><li><constructor-arg index=&quot;4&quot; ref=&quot;CurrencySpreadRecordDAO&quot;/> </li></ul><ul><li></bean> </li></ul>
    68. 68. Spring performs construction <ul><li>public class MyMarketDataFacade implements MarketDataFacade { </li></ul><ul><li>… </li></ul><ul><li>public MyMarketDataFacade( </li></ul><ul><li>DrivenPairRecordDAO drivenPairsDAO, </li></ul><ul><li>VolSmileRecordDAO volSmileRecordDAO, </li></ul><ul><li>SpotRateRecordDAO spotRateRecordDAO, </li></ul><ul><li>VolSpreadRecordDAO volSpreadRecordDAO, CurrencySpreadRecordDAO currencySpreadRecordDAO) { </li></ul><ul><li>… </li></ul>
    69. 69. Look Up Service <ul><li>public class DataLayer { </li></ul><ul><li>private final ApplicationContext ctx; </li></ul><ul><li>public DataLayer() { </li></ul><ul><li>ctx = new ClassPathXmlApplicationContext(&quot;config.xml&quot;); </li></ul><ul><li>} </li></ul><ul><li>public MarketDataFacade getMarketDataFacade() { </li></ul><ul><li>return (MarketDataFacade) ctx.getBean(&quot;MarketDataDao&quot;); </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>
    70. 70. But… <ul><li>These frameworks are not silver bullets. They each have their own problems. </li></ul>
    71. 71. Avoiding Architectural Breakers Course grained decisions that are hard to refactor away from. For example embedding business logic in a UI.
    72. 72. Summary So Far <ul><li>Software is soft so design is an evolving process not a prescribed one. </li></ul><ul><li>Architecture is about controlling the limits of design. </li></ul><ul><li>Architecture is also about pushing a group of developers in a certain direction. It is a soft skill as much as a technical one. </li></ul><ul><li>Patterns and frameworks are the tools the architect uses to do this. </li></ul>
    73. 73. How design can go wrong
    74. 74. The overuse of design patterns => Obtuse code
    75. 75. Fragile Base Class Problem <ul><li>Why does this occur? </li></ul>A B C
    76. 76. Solutions <ul><li>Favour composition over inheritance. </li></ul><ul><li>Superclasses should call subclasses not the other way around </li></ul>
    77. 77. Service Duplication Problem UI Layer Application Layer Technical Decomposition into layering Trade Service Data Service Pricing Service Functional Decomposition into Services Domain Model, Utilities etc
    78. 78. Command/Executor Problem
    79. 79. Solution Be wary of functional decomposition and its tendency to push you away from reuse
    80. 80. In Conclusion <ul><li>Comprehensibility is the goal of design (followed by changeability). </li></ul><ul><li>An architects role is primarily one of communicating and coordinating a common vision. </li></ul><ul><li>If design is to be dynamic unit tests are mandatory. </li></ul>
    81. 81. And finally… Never listen to an architect who does not write code. Conversely if you are an architect, make sure you get your hands dirty.

    ×