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

1. Design and Architecture in Industry The agile viewpoint Ben Stopford Thoughtworks

4. So how to we avoid this?

5. We Architect our System

6. … with UML

7. AND… We get to spot problems early on in the project lifecycle. Why is that advantageous?

8. Because it costs less Low cost of change early in lifecycle

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. Well this is what we used to do… … but problems kept cropping up…

13. Ahhh, those pesky users, why can’t they make up their minds?

14. So… …in summary…

15. We find designing up front hard…

16. ...and a bit bureaucratic

17. … and when we do get it right the users generally go and change the requirements…

18. … and it all changes in the next release anyway.

19. So are we taking the right approach

20. Software is supposed to be soft. That means it is supposed to be easy to change.

22. So is fixing the architecture and design up front the right way to do it?

23. Does the cost curve have to look like this?

24. Can we design our systems so that we CAN change them later in the lifecycle?

25. The Cost of Change in an agile application

26. How

27. By architecting and designing for change ** But not designing for any specific changes *** And writing lots and lots of tests

28. Agile Development facilitates this Code Base Test Test Test

30. This means that your system’s design is constantly evolving.

32. So what does this imply for the Architect?

33. Architecture becomes about steering the application so that it remains easy to understand and easy to change.

34. With everyone being responsible for the design.

35. So the architects role becomes about steering the applications design through others.

36. Shepherding the team!

38. Timeline Set-up Architecture Push patterns and reuse Watch for architectural breakers Amend Architecture

42. 2. Architecture through patterns

43. Separation of Concerns: Layers and Services

45. Model-View-Controller

46. A Real SOA and Layered System Rightmove.com

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

52. Layers and Tiers

55. Aside – Bob’s Website Client Application Layer DB Javascipt Calculation Which way is best?? Client Application Layer DB Server Calculation

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. What is the point of having layers? Separation of Technical Concerns

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. 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

61. 3. Use of frameworks to enforce design principals

63. Aside: What is wrong with the singleton pattern?

71. Avoiding Architectural Breakers Course grained decisions that are hard to refactor away from. For example embedding business logic in a UI.

73. How design can go wrong

74. The overuse of design patterns => Obtuse code

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. Command/Executor Problem

79. Solution Be wary of functional decomposition and its tendency to push you away from reuse

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.