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.
Upcoming SlideShare
What to Upload to SlideShare
What to Upload to SlideShare
Loading in …3
×
1 of 47

Deep Dive into the Idea of Software Architecture

2

Share

Download to read offline

This talk was an experiment in combining a number of ideas I'd been learning and thinking about into a coherent presentation, that would hopefully be useful. The was to give a solid grounding to the idea of software architecture, including taking a critical look at what it is and if it really matters. It then moves into the topics of boundaries and abstractions, horizontal and vertical layers, cross-cutting concerns, "Clean Architecture" and the Dependency Rule it rests upon. It was presented internally at Genesis Energy in September 2018.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Deep Dive into the Idea of Software Architecture

  1. 1. Introduction and deep dive into the idea of Software Architecture Matt Clarke - Genesis Energy - Sep 2018
  2. 2. What we’ll (aim to) cover • Grounding for the idea of software architecture • What is it and does it really matter? • Boundaries, Abstractions and Layers • Package by layer vs. package by feature • Brief overview of Clean Architecture • The Dependency Rule • How and why software architecture can go wrong • Parallels with Agile • Skin in the Game and the role of Architects
  3. 3. What is Software Architecture?
  4. 4. What is a part of the Software Architecture? • Choice of programming language? • Choice of UI framework? • REST vs. GraphQL? • Choice of logging, analytics or monitoring tool? • Authentication & authorization library? • Web vs. mobile vs. terminal front-end?
  5. 5. • These things are important… • But they’re of secondary importance to the software’s architecture • They’re still details, relatively speaking • They are not (or should not) be architectural/foundational to your software
  6. 6. What is software architecture?
  7. 7. What is software architecture? • Why does this distinction matter? Why bother thinking about your software in this way? What makes you think this is more important than choice of UI framework or database? • Why does the structure of your project at the highest level matter?
  8. 8. What does a badly- architected project look like?
  9. 9. What does a badly architected project look like? • Spaghetti code • No clear boundaries (or ‘rooms’) • Everything knows about everything else • Hard to find what you’re looking for • Chaotic - difficult to see patterns or logic • Difficult to test - parts or the whole system
  10. 10. But why are any of these things necessarily bad?
  11. 11. Why is an unstructured, chaotic, unclear project actually bad? • Let’s begin by assuming it would be a good thing for the world if your software was useful to your customer • From this it follows that your software becoming increasingly useless over time would be a bad thing • Unstructured, tangled code makes it difficult to keep the software matching the customer’s needs over time • If this trend continues, customers stop paying for your product • Eventually, your project will be “sunset” or company will go bankrupt • I.e. badly architected code is unsustainable
  12. 12. The world is changing • “The world is changing which means your business needs to change, which means your software needs to change” - Marcus Biel • James McGill: “competitors, regulations, technology and customer appetites are changing” • Product/Market fit is a function of both product and market • If the market is moving (and it always is) and your product isn’t, it’s getting worse • Another key point: market changes are largely unpredictable due to the reality of limited information
  13. 13. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"
  14. 14. Code rot • The situation where code is too difficult/complex to change to keep up with demands is sometimes known as code rot • When a project or business fails due to technical reasons, it’s usually due to code rot • I.e. unmanageable complexity
  15. 15. “Projects fail most often because of poor requirements, poor planning, or poor management. But when projects do fail for reasons that are primarily technical, the reason is often uncontrolled complexity. The software is allowed to grow so complex that no one really knows what it does.”
  16. 16. Does Software Architecture matter? • At the very least, we’ve established that having a bad architecture matters, in the negative sense • Uncontrolled complexity = eventual project failure • Implication: getting away from bad/no architecture matters • What would characterise a “good architecture” then?
  17. 17. Well-designed architecture? • Is a tool for humans to keep software complexity manageable… • …so that we can easily and safely change it to keep up with the environment
  18. 18. Well-designed architecture? • A good architecture optimises the source code for humans to “live in” (read: understand and freely change) • Particularly: a good software architecture is optimised for the fact that human processing speed and working memory is very limited (relative to a machine) • Code complexity is a problem for humans, not machines (relatively speaking)
  19. 19. The Humble Programmer - Edsger W. Dijkstra (1972) • “We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.”
  20. 20. Well-designed architecture? • A good architecture lets you step into an area of the system to make a needed change, safely ignoring everything outside for a while • Like entering a room in a house • Ideally, everything you need is at hand. You don’t need to search each room of the house for the ingredients to cook dinner • How can this be achieved?
  21. 21. Boundaries • Boundaries are a tool for holding back complexity/ chaos • They simplify the world by limiting the number of things that need to be considered at once • A software architecture could be described as the choice of boundaries and connections between bounded areas (dependencies)
  22. 22. Boundaries • Bounded components are also a form of redundancy • Redundancy limits the impact caused by unexpected changes in requirements • Impact of changes can be contained to a few components rather than affecting the entire system (full regression!) • Redundancy makes the software more robust to future changes
  23. 23. Types of software boundaries • Function • Class • Interface • Package/directory • Module • Library • Process on the same machine • Process on another machine (API boundary)
  24. 24. Boundary <-> abstraction • Boundaries in software are represented by abstractions • Abstraction: “The act of abstracting, separating, withdrawing, or taking away; withdrawal; the state of being taken away.” • The essence of abstractions is preserving information that is relevant in a given context, and forgetting information that is irrelevant in that context. – John V. Guttag • Abstractions hide irrelevant details, reducing complexity, temporarily simplifying the world
  25. 25. Boundary <-> abstraction
  26. 26. Boundary <-> abstraction public interface MusicPlayer { void play(); void pause(); void stop(); void next(); void previous(); }
  27. 27. Choice of boundaries • So boundaries/abstractions are a good tool we can use to limit complexity • Does this mean we just need to add lots of boundaries to our code to make it easier to understand? • Drawing boundaries around something defines a category - it groups things together based on them being similar in some way • There’s a (near?) infinite number of ways you could groups things • Given that, how should you group code together optimally? How do you choose where to draw boundaries?
  28. 28. Well-designed architecture? • A good architecture lets you step into an area of the system to make a needed change, safely ignoring everything outside for a while • Like entering a room in a house • Ideally, everything you need is at hand. You don’t need to search each room of the house for the ingredients to cook dinner
  29. 29. Well-designed architecture? • A choice of rooms that reduces the amount of room changes (read: context switches) while going about daily life would be make life easier • Also the number of purposes for the room should be limited, to limit effectively limit complexity
  30. 30. Well-designed architecture? • If a good architecture optimises the source code for humans to “live in” (understand and freely change)… • And the point of changes is to make the software more useful to the customer in some way… • Then it makes sense to group together code that typically changes for the same reasons, or needs changing at the same time • This way when you find the right room (component/ module…), you have everything at hand to make the desired business change
  31. 31. Layered Architecture • What are some classes of changes that commonly occur at the same time? • 3 tier architecture: Presentation/UI Domain/Business Data
  32. 32. Layered Architecture • Here’s another valid way you could slice up code: by feature (or use case) Presentation/UI Domain/Business Data Login Elec. Gas LPG Bills
  33. 33. Layered Architecture • Cross-cutting concerns: affect (at minimum) all vertical slices. Possibly all parts of the app. Presentation/UI Domain/Business Data Login Elec. Gas LPG Bills Logging,
 analytics,
 monitoring…
  34. 34. Layered Architecture Presentation/UI Domain/Business Data Login Elec. Gas LPG Bills presentation/
 login/
 electricity/
 gas/
 domain/
 login/
 electricity/
 gas/
 data/
 login/
 electricity/
 gas/
  35. 35. Layered Architecture Presentation/UI Domain/Business Data Login Elec. Gas LPG Bills login/
 presentation/
 domain/
 data/
 electricity/
 presentation/
 domain/
 data/
 gas/
 presentation/
 domain/
 data/
  36. 36. The Dependency Rule • Low-level details depend on high-level policy • High-level business logic depends on abstractions • These abstractions are depended on and implemented by concrete, low-level details • “ In general, the further in you go, the higher level the software becomes. The outer circles are mechanisms. The inner circles are policies.
 
 The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle.”
  37. 37. Agile Parallel • Dependency Rule -> the Clean Architecture • Agile principles -> Scrum
  38. 38. Questions/discussion

×