Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Simon Brown: Software Architecture as Code at I T.A.K.E. Unconference 2015

1,184 views

Published on

Simon Brown: Software Architecture as Code at I T.A.K.E. Unconference 2015

Published in: Software
  • Be the first to comment

Simon Brown: Software Architecture as Code at I T.A.K.E. Unconference 2015

  1. 1. Simon Brown @simonbrown Software Architecture as Code
  2. 2. Jersey
  3. 3. Jersey
  4. 4. Jersey
  5. 5. I help software teams understand software architecture, technical leadership and the balance with agility
  6. 6. Software architecture needs to be more accessible
  7. 7. A developer-friendly guide to software architecture, technical leadership and the balance with agility
  8. 8. I code too ⇧ ; - ⇧ 0
  9. 9. The intersection between software architecture and code
  10. 10. How do we communicate software architecture?
  11. 11. The tension between software architecture and code
  12. 12. It’s usually difficult to show the entire design on a single diagram Different views of the design can be used to manage complexity and highlight different aspects of the solution
  13. 13. Software architecture deals with abstraction, with decomposition and composition, with style and esthetics. To describe a software architecture, we use a model composed of multiple views or perspectives. Architectural Blueprints—The “4+1” View Model of Software Architecture by Philippe Kruchten
  14. 14. Do the names of those views make sense? Development vs Physical Process vs Functional Conceptual vs Logical Development vs Implementation Physical vs Implementation Physical vs Deployment
  15. 15. Logical and development views are often separated
  16. 16. Brain freeze!
  17. 17. 9 out of 10 people don’t use UML (in my experience)
  18. 18. In my experience, software teams aren’t able to effectively communicate the software architecture of their systems
  19. 19. The Airline Route Map
  20. 20. Generically True
  21. 21. Homeless Old C# Object (HOCO)
  22. 22. Choose your own adventure
  23. 23. Would we code it that way?
  24. 24. Did we code it that way?
  25. 25. Abstraction is about reducing detail rather than creating a different representation
  26. 26. Abstractions help us reason about a big and/or complex software system
  27. 27. Does your code reflect the abstractions that you think about?
  28. 28. We often think in components but write classes (usually in layers)
  29. 29. Package by layer (horizontal slicing) Presentation layer Business layer Data layer Controller BController A Data Access A Data Access B Service BService A
  30. 30. Package by layer (horizontal slicing) Presentation layer Business layer Data layer Controller BController A Data Access A Data Access B Service BService A Controller C Service C Data Access C
  31. 31. Hexagons and onions
  32. 32. Should layers be considered harmful?
  33. 33. Are layers significant structural elements or just an implementation detail?
  34. 34. Package by feature (vertical slicing) Feature Set BFeature Set A Controller BController A Data Access A Data Access B Service BService A
  35. 35. Organisation of code vs the architectural views
  36. 36. “the model-code gap”
  37. 37. Sketches get out of date, so why not auto-generate the diagrams?
  38. 38. Diagramming tools see packages and classes rather than components
  39. 39. Describing software architecture
  40. 40. “Modules, components and connectors” Is this vocabulary in common use?
  41. 41. “This is a component of our system” says one developer to another, pointing to a box on a diagram labelled “Web Application”
  42. 42. A common set of abstractions is more important than a common notation
  43. 43. Agree on a simple set of abstractions that the whole team can use to communicate Class Class Class Component Component Component Container (e.g. web application, application server, standalone application, browser, database, file system, etc) Cont (e.g. web application browser, databas ainer file system, etc) Software System
  44. 44. The C4 model Classes Component or pattern implementation details System Context The system plus users and system dependencies Containers The overall shape of the architecture and technology choices Components Logical components and their interactions within a container
  45. 45. Context •What are we building? •Who is using it? (users, actors, roles, personas, etc) •How does it fit into the existing IT environment? (systems, services, etc)
  46. 46. Containers •What are the high- level technology decisions? (including responsibilities) •How do containers communicate with one another? •As a developer, where do I need to write code?
  47. 47. Components •What components/ services is the container made up of? •Are the technology choices and responsibilities clear?
  48. 48. A notationless notation (whiteboard and sticky note friendly, supplemented with colour coding) My Web Application [Container: Apache Tomcat 7.x] Here is a list of the key responsibilities for my web application.
  49. 49. Classes Component or pattern implementation details System Context The system plus users and system dependencies Containers The overall shape of the architecture and technology choices Components Logical components and their interactions within a container Overview first Zoom and filter Details on demand Shneiderman’s mantra
  50. 50. Diagrams are maps that help a team navigate a complex codebase
  51. 51. Think about the target audience Non-technical Semi-technical Very technical
  52. 52. C4++Enterprise context User interface mockups and wireframes Domain model Sequence and collaboration diagrams Business process and workflow models Infrastructure model Deployment model ...
  53. 53. 4+1 architectural view model Philippe Kruchten Software Systems Architecture Working with Stakeholders Using Viewpoints and Perspectives (2nd Edition) Nick Rozanski and Eoin Woods
  54. 54. Static Model (at different levels of abstraction) Runtime/ Behavioural Deployment Infrastructure Operation & Support Data
  55. 55. C4 is about the static structure of software, which is ultimately about code
  56. 56. Software developers are the most important stakeholders of software architecture
  57. 57. Components?
  58. 58. What is a “component”?
  59. 59. Spring PetClinic https://github.com/spring-projects/spring-petclinic/ 3-profiles- jdbc- default-(JPA)- Spring-Data-JPA- Repository Service @Cacheable- @TransacGonal- Controller Bean-ValidaGon- Spring-@MVC-annotaGons- Views Bootstrap-(CSS)- JSP-with-- custom-tags- Thymeleaf- Dandelion-webjars- | | &&&&+ https://speakerdeck.com/michaelisvy/ spring-petclinic-sample-application
  60. 60. An auto- generated UML class diagram
  61. 61. What are the architecturally significant elements?
  62. 62. A UML class diagram showing architecturally significant elements
  63. 63. A component diagram, based upon the code
  64. 64. How do we do this? Can we extract the software architecture model from the code? How do we create living documentation? What is the relationship between architecture, coding and testing? Will I talk about microservices? Why is this important?
  65. 65. The intersection of software architecture and code
  66. 66. Merge the code and the model?
  67. 67. Abstractions on diagrams should reflect the code
  68. 68. “architecturally-evident coding style” (subclassing, naming conventions, module dependencies, package structure, …)
  69. 69. What’s a “component”?
  70. 70. Package by component Component B Feature Set BFeature Set A Component A Controller BController A Data Access A Data Access B Service BService A
  71. 71. What’s a “component”?
  72. 72. Architecturally-evident coding styles include: Annotations/attributes (@Component, [Component], etc) Naming conventions (*Service) Namespacing/packaging (com.mycompany.system.components.*) Maven modules, OSGi modules, microservices, etc
  73. 73. Modularity as a principle
  74. 74. Software architecture vs testing (a quick aside)
  75. 75. “In the early days of computing when computers were slow, unit tests gave the developer more immediate feedback about whether a change broke the code instead of waiting for system tests to run. Today, with cheaper and more powerful computers, that argument is less persuasive.”
  76. 76. “do not let your tests drive your design”
  77. 77. What’s a “component”?
  78. 78. Instead of blindly unit testing everything, what about testing your significant structural elements as black boxes?
  79. 79. Do we need to rethink the testing pyramid? UI and functional Integration Unit
  80. 80. Architecturally-aligned testing (and a reshaped testing pyramid) Class Tests Tests focused on individual classes and methods, sometimes by mocking out dependencies (typically referred to as “unit” tests) Component and Service Tests Tests focused on components and services through their public interface (often referred to as “integration” tests) System Tests UI, API, functional and acceptance tests (“end-to-end” tests)
  81. 81. Software architecture as code
  82. 82. The code is the embodiment of the architecture
  83. 83. Is the architecture in the code?
  84. 84. In practice, architecture is embodied and recoverable from code, and many languages provide architecture- level views of the system. A Survey of Architecture Description Languages by Paul C. Clements
  85. 85. Context Software Systems Integration points, APIs, known libraries, credentials for inbound consumers, etc. Containers IDE projects/modules, build output (code and infrastructure), etc. People Security groups/roles in configuration files, etc. Components Extractable from the code if an architecturally-evident coding style has been adopted.
  86. 86. Containers Software Systems Integration points, APIs, known libraries, credentials for inbound consumers, etc. Containers IDE projects/modules, build output (code and infrastructure), etc. People Security groups/roles in configuration files, etc. Components Extractable from the code if an architecturally-evident coding style has been adopted.
  87. 87. Components Software Systems Integration points, APIs, known libraries, credentials for inbound consumers, etc. Containers IDE projects/modules, build output (code and infrastructure), etc. People Security groups/roles in configuration files, etc. Components Extractable from the code if an architecturally-evident coding style has been adopted.
  88. 88. Extract as much of the software architecture from the code as possible, and supplement where necessary
  89. 89. Create an architecture description language using code
  90. 90. Structurizr for Java (open source on GitHub)
  91. 91. Structurizr Simple, versionable, up-to-date and scalable software architecture models from code
  92. 92. Spring PetClinic - System Context
  93. 93. Spring PetClinic - Containers
  94. 94. Spring PetClinic - Web Application - Components
  95. 95. A model as code provides opportunities…
  96. 96. …and build pipeline integration keeps software architecture models up-to-date
  97. 97. Software architecture really is for developers :-)
  98. 98. The point of this?
  99. 99. Maintainability is inversely proportional to the number of public classes dependencies microservices[ ]
  100. 100. A good architecture enables agility
  101. 101. Monolithic architecture Service-based architecture (SOA, micro-services, etc) Something in between (components)
  102. 102. Agility is a quality attribute
  103. 103. If you can’t build a structured monolith, what makes you think microservices is the answer!?
  104. 104. Well-defined, in-process components is a stepping stone to out-of-process components (i.e. microservices) From components to microservices High cohesion Low coupling Focussed on a business capability Bounded context or aggregate Encapsulated data Substitutable Composable <- All of that plus Individually deployable Individually upgradeable Individually replaceable Individually scalable Heterogeneous technology stacks
  105. 105. Choose microservices for the benefits, not because your monolithic codebase is a mess :-)
  106. 106. If your software system is hard to work with, change it!
  107. 107. Think about how to align the software architecture and the code
  108. 108. Be conscious of the software architecture model … adopt an architecturally-evident coding style
  109. 109. Stop making every class public
  110. 110. 1 RON charity donation every time you type without thinking :-) public class
  111. 111. simon.brown@codingthearchitecture.com @simonbrown on Twitter If the software architecture model is in the code, it can be extracted from the code

×