Software Architecture Fundamentals

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Henrique Silvério github.com/HenriqueSilverio twitter.com/RikeSilverio Software Engineer @ IM+

Slide 3

Slide 3 text

The signature of a mess

Slide 4

Slide 4 text

Behavior Vs. Architecture Developer: "Do you want to be able to make changes?" Manager: "Of course! But… functionality is more important than later ﬂexibility…"

Slide 5

Slide 5 text

Behavior Vs. Architecture Manager: "Hey! We need to add this 'little button' to the screen!" Developer: "Ok! We gonna need {insert unaffordable high cost here} to make it." Manager:

Slide 6

Slide 6 text

Fight for the architecture!

Slide 7

Slide 7 text

What is architecture? "The architecture of a software system is the shape given to that system by those who build it." "Low-level details and high-level decisions are part of the whole design." — Robert C. Martin

Slide 8

Slide 8 text

Source: https://br.pinterest.com/pin/817966351053743259/

Slide 9

Slide 9 text

Source: https://coolhouseconcepts.com/house-plans/three-bedroom-cool-house-concept/

Slide 10

Slide 10 text

Source: https://libraries.usc.edu/library-ﬂoor-plans

Slide 11

Slide 11 text

Architecture is about intent. So why we came at this:

Slide 12

Slide 12 text

Hm! It's a Laravel app! It's a Web app!

Slide 13

Slide 13 text

Uh! It's a Ruby on Rails app! It's a Web app!

Slide 14

Slide 14 text

Architecture goals "The purpose [...] is facilitate the development, deployment, operation, and maintenance of the software system" "The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity." "The strategy behind that facilitation is to leave as many options open as possible, for as long as possible." — Robert C. Martin

Slide 15

Slide 15 text

Keep options open!

Slide 16

Slide 16 text

A Use Case Driven Approach

Slide 17

Slide 17 text

Use Cases Application speciﬁc business rules.

Slide 18

Slide 18 text

Design Principles SRP: Single Responsibility Principle OCP: Open-Closed Principle LSP: Liskov Substitution Principle ISP: Interface Segregation Principle DIP: Dependency Inversion Principle

Slide 19

Slide 19 text

Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. — "Agile Software Development, Principles, Patterns, and Practices", Robert C. Martin

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

Domain Application agnostic business rules.

Slide 22

Slide 22 text

Boundaries

Slide 23

Slide 23 text

The Web is a detail.

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

The Database is a detail.

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

Show me the code. The BMI Calculator example.

Slide 28

Slide 28 text

Standing on the shoulders of Giants

Slide 29

Slide 29 text

Thank you! Henrique Silvério github.com/HenriqueSilverio twitter.com/RikeSilverio