Software Architecture Primer

Transcript

1. Software Architecture Primer Y Soft Knowledge Sharing (based on the PV260 Course at FI@MU) 1 Ondřej “Ondra” Krajíček ondrej.krajicek@ysoft.com @OndrejKrajicek
2. • My perception of Software Architecture significantly evolved over the last 20 years. • Software Architecture is often counter-intuitive, generally hard and has steep learning curve. There is no single right way how to do it and there are no stupid questions. • This is a gentle introduction to Software Architecture and an overview of basic architectural styles. • Should you want to dig deeper into anything and everything, let me know and I will prepare a session to discuss more specific topic.
3. This talk represents my view of the world and my experience. I am only sharing my insight and ideas. I do not claim that this is the only right way how to do SWA.
4. Let’s dig in…
5. Antoine de Saint Exupéry “Perfection is not achieved when there is nothing to add, but when there is nothing to remove.”
6. IETF RFC 1925 “It has to work.” Each change must result in sellable product.
7. Principles over patterns. Ondra
8. Software Architecture is the important stuff (whatever that is). Ralph Johnson
9. The most important KPI of software architecture is Cost of Change. How can we measure the CoC? Lead Time / Cycle Time Money Story Points … Copyright (c) 2006-2009 Scott W Ambler
10. SERVANT OF HIGH-PRIORITY STAKEHOLDER VALUES AS SIMPLE AS POSSIBLE, NOT SIMPLER DESIGNED TO BE REPLACEABLE
11. Software Architecture is Strategy Strategy is a plan how to deliver on your goals. Your goals are defined by high-priority stakeholders.
12. SOFTWARE ARCHITECTURE AS STRATEGY • WHO ARE THE HIGH PRIORITY STAKEHOLDERS? • WHAT ARE THEIR NEEDS / INTERESTS / STAKEHOLDER VALUES? • HOW DO WE MAKE SURE THAT OUR SYSTEM IS AS SIMPLE AS POSSIBLE? • WHAT DO WE DO TO KEEP COST OF CHANGE UNDER CONTROL? • HOW DO WE ENSURE THAT OUR ARCHITECTURE IS REPLACEABLE?
13. Software Architecture is Risk Mitigation What happens when things go wrong? Is it important? What are the risks? Who knows them? How can we manage risk? • Software Architect needs to start this discussion (if no one else does) • Software Architect needs to make sure we have the answers
14. Software Architect is (first and foremost) a Teacher
15. SOFTWARE ARCHITECTURE IS DONE BY EVERYONE.
16. The Software Architect designation is less about the job, a bit more about a role, but mostly about mindset and maturity level.
17. 30 Minutes Software Architecture Crash Course
18. Architectural Styles • Tiered Architecture • Hexagonal Architecture • Onion Architecture • Object Oriented Architecture • Service Oriented Architecture • Microservices
19. Which one is the best one?
20. • Consistency • Cohesion • Coupling • Clarity Cost of Change
21. Principles over Patterns. Consistency
22. Module, Data, Service, Interaction Dependencies. Coupling https://www.javatpoint.com/software-engineering-coupling-and-cohesion
23. Well-Designed or Leaking Abstractions. Cohesion https://www.javatpoint.com/software-engineering-coupling-and-cohesion
24. Everyone understands principles, scopes, shapes and impact of changes. Clarity
25. Overview of Architectural Styles
26. 2-Tier Architecture • Original Client / Server • Business Logic is implemented on the client, server or both. • What are the issues?
27. 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 different from 2-Tier? https://en.wikipedia.org/wiki/Multitier_architecture#/media/File:Overview_of_a_three-tier_application_vectorVersion.svg
28. Is SafeQ 6 3-Tier Architecture?
29. 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 different from N-Tier?
30. 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/
31. 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.
32. So what does the architecture of your application scream? When you look at the top level directory structure, and the source files 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
33. Microservices also known as the current silver bullet. https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html
34. Organization structure determines system architecture / design. https://medium.com/@learnstuff.io/conways-law-in-software- dev-3aa6324ead52
35. 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
36. • 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
37. What are the challenges of Microservices? Compensating for high decentralisation. Patterns are emerging. Yet another silver bullet?
38. API Gateway Pattern Thank you NETFLIX! https://microservices.io/patterns/apigateway.html
39. Going back and forth… why are some teams fine with monoliths? • Duplication and lack of consistency • Difficult or wrong decoupling of functional units • Lack of discipline • Teams only accept responsibility for “their" services • Diversity in technologies increases costs
40. Beyond Microservices - Server-less architectures From Short Lived Jobs to Components to Services to Microservices to Short Lived Jobs again.
41. Osaka Castle
42. Giza Pyramids
44. Replaceable as in improve system quality without impacting business logic. Quality? Security, Flexibility, Scalability…
45. WHAT TO REMEMBER
46. Architecture is a servant of high priority stakeholder values. Is as simple as possible, but not simpler. Is designed to be replaceable.
47. Software Architecture is a Strategy. Software Architecture is Communication. Software Architect is a Teacher.