Software Architecture Primer

An introductory talk about Software Architecture given as part of the PV260 course at Faculty of Informatics, Masaryk University in Brno, Czech Republic.

Transcript

1. What is Software Architecture… and an overview. PV260 Software Quality 1 Ondřej “Ondra” Krajíček ondrej.krajicek@ysoft.com @OndrejKrajicek
2. Antoine de Saint Exupéry “Perfection is not achieved when there is nothing to add, but when there is nothing to remove.”
3. (attributed to) Albert Einstein “Insanity is doing the same thing over and over and expecting different results.”
4. IETF RFC 1925 “It has to work.”
5. Software Architecture is seldom about functional requirements.
7. Software Architecture is the important stuff 
 (whatever that is). Ralph Johnson
8. Cost of Change Curve Copyright (c) 2006-2009 Scott W Ambler
9. Cost of Change Curve Copyright (c) 2006-2009 Scott W Ambler
10. SOFTWARE ARCHITECTURE IS THE SERVANT OF HIGH-PRIORITY STAKEHOLDER VALUES. IS AS SIMPLE AS POSSIBLE, BUT NOT SIMPLER AND IS DESIGNED TO BE REPLACEABLE. Tom Gilb (Architecture Manifesto)
11. SERVANT HIGH-PRIORITY STAKEHOLDER VALUES AS SIMPLE AS POSSIBLE NOT SIMPLER REPLACEABLE
12. Software Architecture is Strategy Strategy is a plan how to deliver on your goals. Your goals are de fi ned by high-priority stakeholders.
13. SOFTWARE ARCHITECTURE IS THE STRATEGY HOW TO DELIVER HIGH-PRIORITY STAKEHOLDER VALUES.
14. SOFTWARE ARCHITECTURE IS THE STRATEGY HOW TO DELIVER HIGH-PRIORITY STAKEHOLDER VALUES. It is still important to accept change because no battle plan survives the fi rst contact with the enemy.
15. Software Architecture is Risk Mitigation What happens when things go wrong? Is it important?
16. Software Architecture is Communication What does it mean? How to deliver and protect stakeholder values?
17. Software Architect is a Teacher
18. Who does software architecture then?
19. Who does software architecture then? Software Architecture is done by everyone.
20. 60 Minutes Software Architecture Crash Course
21. Architectural Styles • Tiered Architecture • Hexagonal Architecture • Onion Architecture • Object Oriented Architecture • Service Oriented Architecture • Microservices
22. Which one is the best one?
24. • Consistency
25. • Consistency • Cohesion
26. • Consistency • Cohesion • Coupling
27. • Consistency • Cohesion • Coupling • Clarity
28. • Consistency • Cohesion • Coupling • Clarity
29. • Consistency • Cohesion • Coupling • Clarity Cost of Change
30. Principles over Patterns. Consistency
31. Principles over Patterns. Consistency
32. Principles over Patterns. Consistency
33. Module, Data, Service, Interaction Dependencies. Coupling
34. Module, Data, Service, Interaction Dependencies. Coupling
35. Module, Data, Service, Interaction Dependencies. Coupling https://www.javatpoint.com/software-engineering-coupling-and-cohesion
36. Well-Designed or Leaking Abstractions. Cohesion
37. Well-Designed or Leaking Abstractions. Cohesion
38. Well-Designed or Leaking Abstractions. Cohesion https://www.javatpoint.com/software-engineering-coupling-and-cohesion
39. Everyone understands why, how and what to do. System deteriorates slower and technical debt does not grow quickly. Clarity
40. Everyone understands why, how and what to do. System deteriorates slower and technical debt does not grow quickly. Clarity
41. Replaceable Architecture Wait, what?
42. Osaka Castle
43. Giza Pyramids
45. • Built to last: hundreds and thousands of years.
46. • Built to last: hundreds and thousands of years. • Built to survive natural disasters, especially earthquakes (shinbashira).
47. • Built to last: hundreds and thousands of years. • Built to survive natural disasters, especially earthquakes (shinbashira). • Both have very different architecture.
48. • Built to last: hundreds and thousands of years. • Built to survive natural disasters, especially earthquakes (shinbashira). • Both have very different architecture. • You cannot replace one with the other.
49. • Built to last: hundreds and thousands of years. • Built to survive natural disasters, especially earthquakes (shinbashira). • Both have very different architecture. • You cannot replace one with the other. • Why would you?
50. Replaceable as in Having rather low Cost of Change How to decrease Cost of Change?
51. 2-Tier Architecture • Original Client / Server • Business Logic is implemented on the client, server or both. • What are the issues?
52. 3-Tier Architecture • Decouple presentation from business logic. Business logic is isolated from client and server. • Business layer often historically hosted in application servers with obscure technologies (j2ee, Microsoft ASP, PHP, ColdFusion, etc.). • How is it di ff erent from 2-Tier? https://en.wikipedia.org/wiki/Multitier_architecture#/media/File:Overview_of_a_three-tier_application_vectorVersion.svg
53. Onion Architecture • Built on the observation that most / all interfaces are alike. • Outer layers depend on inner layers. • Inner layers must not depend on outer layers. • Enforces Inversion of Control. • How is it di ff erent from N-Tier?
54. Onion Architecture • Built on the observation that most / all interfaces are alike. • Outer layers depend on inner layers. • Inner layers must not depend on outer layers. • Enforces Inversion of Control. • How is it di ff erent from N-Tier?
55. Hexagonal Architecture • Ports and Adapters Architecture • Sometimes Onion and Hexagonal are viewed as the same. • Hexagonal Architecture is more explicit and structured. • Recommended reading:
 https://herbertograca.com/2017/11/16/ explicit-architecture-01-ddd-hexagonal- onion-clean-cqrs-how-i-put-it-all-together/
56. Hexagonal Architecture • Ports and Adapters Architecture • Sometimes Onion and Hexagonal are viewed as the same. • Hexagonal Architecture is more explicit and structured. • Recommended reading:
 https://herbertograca.com/2017/11/16/ explicit-architecture-01-ddd-hexagonal- onion-clean-cqrs-how-i-put-it-all-together/
57. The Clean Architecture • Onion + Screaming Architecture. • Independent of Frameworks. • Testable: all parts and as a whole. • Independent of Interfaces. • Independent of the data store / database / object persistence. • Independent of any external impact.
58. So what does the architecture of your application scream?
59. So what does the architecture of your application scream?
60. So what does the architecture of your application scream? When you look at the top level directory structure, and the source fi les in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System?
61. So what does the architecture of your application scream? When you look at the top level directory structure, and the source fi les in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System?
62. So what does the architecture of your application scream? When you look at the top level directory structure, and the source fi les in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System? Do they scream global, distributed, consistent or available?
63. So what does the architecture of your application scream? When you look at the top level directory structure, and the source fi les in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System? Do they scream global, distributed, consistent or available?
64. So what does the architecture of your application scream? When you look at the top level directory structure, and the source fi les in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System? Do they scream global, distributed, consistent or available? Or do they scream: Rails, or Spring/Hibernate, or ASP?
65. So what does the architecture of your application scream? When you look at the top level directory structure, and the source fi les in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System? Do they scream global, distributed, consistent or available? Or do they scream: Rails, or Spring/Hibernate, or ASP?
66. So what does the architecture of your application scream? When you look at the top level directory structure, and the source fi les in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System? Do they scream global, distributed, consistent or available? Or do they scream: Rails, or Spring/Hibernate, or ASP? Recommended viewing: https://www.youtube.com/watch?v=ZsHMHukIlJY
67. Microservices also known as the current silver bullet. https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html
68. Microservices also known as the current silver bullet. https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html
69. Organization structure determines system architecture / design. https://medium.com/@learnstu ff .io/conways-law-in-software- dev-3aa6324ead52
70. As the systems get larger, complexity grows quickly and systems become unmanageable. http://www.laputan.org/mud/mud.html#BigBallOfMud https://medium.com/raa-labs/part-1-domain-driven-design-like-a-pro-f9e78d081f10
71. • Split system in a set of loosely coupled, cohesive services. • Each service does only one thing and does it well. • Each service is represented only by its API. • Each service has its own data. Microservices https://medium.com/hashmapinc/the-what-why-and-how-of-a-microservices-architecture-4179579423a9
72. What are the challenges of Microservices? Compensating for high decentralisation. Patterns are emerging.
73. API Gateway Pattern Thank you NETFLIX! https://microservices.io/patterns/apigateway.html
74. The absolute minimum to remeber.
76. Architecture is a servant of high priority stakeholder values.
77. Architecture is a servant of high priority stakeholder values. Is as simple as possible, but not simpler.
78. Architecture is a servant of high priority stakeholder values. Is as simple as possible, but not simpler. Is designed to be replaceable.
80. Software Architecture is a Strategy.
81. Software Architecture is a Strategy. Software Architecture is Communication.
82. Software Architecture is a Strategy. Software Architecture is Communication. Software Architect is a Teacher.
83. Feel free to connect.