Software Architecture Journey

Slide 1

Slide 1 text

Software Architecture journey @alexsimonescu

Slide 2

Slide 2 text

Software Architecture with a taste of Clean, Hexagonal and DDD

Slide 3

Slide 3 text

Why?

Slide 4

Slide 4 text

Why we want a architecture? ● Unified code style ● Unified code structure ● Stable platform ● Fast development ● Tell me yours!! Milanuncios Dev Team

Slide 5

Slide 5 text

Why to think about architecture?

Slide 6

Slide 6 text

Trends Names change but principles and goals are always the same.

Slide 7

Slide 7 text

What ● Goals ○ Software architecture goals ○ Stakeholders goals ● Clean architecture ● Hexagonal ● Architecture layers and DDD

Slide 8

Slide 8 text

Architecture goals ● Independent of frameworks ● Testable ● Independent of UI ● Independent of database ● Independent of any external agency Robert C. Martin (Uncle Bob)

Slide 9

Slide 9 text

Some product goals ● Scalable ● New features ● Fast bug fixing ● Maybe support pivot Alexandru Simonescu

Slide 10

Slide 10 text

Software architecture evolution Lasagna-Oriented Architecture (aka Layered Monolith) Spaghetti-Oriented Architecture (aka Copy & Paste) Ravioli-Oriented Architecture (aka Microservices)

Slide 11

Slide 11 text

Software architecture evolution Lasagna-Oriented Architecture (aka Layered Monolith) Spaghetti-Oriented Architecture (aka Copy & Paste) Ravioli-Oriented Architecture (aka Microservices) What’s next?

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Our plan? Monolithic Microservices

Slide 14

Slide 14 text

If you can’t build a well-structured monolith, what makes you think microservices is the answer?

Slide 15

Slide 15 text

Hexagonal Architecture

Slide 16

Slide 16 text

“ A.K.A.: Ports and Adapters

Slide 17

Slide 17 text

“ “Allow and application to equally be driven by users, programs or automated tests, and to be developed and tested in isolation from its eventual runtime devices and databases. Alistair Cockburn

Slide 18

Slide 18 text

Key concepts Ports are interfaces Adapters are implementations

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

Domain Application Framework

Slide 22

Slide 22 text

Clean Architecture

Slide 23

Slide 23 text

“ A.K.A.: Onion Architecture Uncle Bob

Slide 24

Slide 24 text

Clean architecture principles ● Independent of frameworks ● Testable ● Independent of UI ● Independent of database ● Independent of any external agency

Slide 25

Slide 25 text

Clean architecture Application Frameworks and Drivers Interface Adapters Application Business Rules Enterprise Business Rules Entities Use Cases Presenters, Controllers, Gateways Web, Frameworks, DB, Devices, UI Entities Use Cases Controllers Presenters Gateways External UI DB Devices Fram ew ork

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Domain Driven Design

Slide 29

Slide 29 text

“ It’s a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. Eric Evans - Domain Driven Design

Slide 30

Slide 30 text

Domain Every software program relates to some activity or interest of its user. That subject area to which the user applies the program is the domain of the software. Eric Evans, “Domain Driven Design”

Slide 31

Slide 31 text

Model A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving problem at hand and ignores extraneous detail. Eric Evans, “Domain Driven Design”

Slide 32

Slide 32 text

Ubiquitous Language It’s a shared jargon between domain experts and developers, based on domain model. Eric Evans, “Domain Driven Design”

Slide 33

Slide 33 text

DDD Building Blocks

Slide 34

Slide 34 text

Entity An object with clear identity and a lifecycle with state transitions that we care about.

Slide 35

Slide 35 text

Value Object An object that contains attributes but has no conceptual identity. They should be treated as immutable.

Slide 36

Slide 36 text

Value Object A small simple object, like money or a date range, whose equality isn’t based on identity. Martin Fowler

Slide 37

Slide 37 text

Anemic Domain Model Both Entity and Value Object should have data and behaviours.

Slide 38

Slide 38 text

Repository ● Acts as if it were an in-memory data store ● In tests, can use a in-memory repository ● ORM is not a Repository ● Like a collection but with complex querying

Slide 39

Slide 39 text

Aggregate A DDD aggregate is a cluster of domain objects that can be treated as a single unit. Martin Fowler

Slide 40

Slide 40 text

Domain Event Captures the memory of something interesting which affects the domain. Martin Fowler

Slide 41

Slide 41 text

N - Layer Architecture

Slide 42

Slide 42 text

“ Just because someone created and named some layers doesn’t mean your application should have them.

Slide 43

Slide 43 text

“ You should create layers AFTER you created substantial amount of code which you grouped together for sake of communication and to clarify code.

Slide 44

Slide 44 text

Layers vs Tiers Presentation Layer Business Layer Data Access Layer Crosscutting Layer Core Core DB DB Front Front

Slide 45

Slide 45 text

Layers Presentation Layer Application Layer Data Access Layer Crosscutting Layer Domain Layer Database API Persistence Infrastructure

Slide 46

Slide 46 text

Layers interaction Controllers User Interface Application Domain Infrastructure Views

Slide 47

Slide 47 text

Domain Layer The heart

Slide 48

Slide 48 text

Domain Layer The domain layer is the heart of the software, and this is where the interesting stuff happens.

Slide 49

Slide 49 text

Application Layer What your application does

Slide 50

Slide 50 text

“ The application layer is responsible for driving the workflow of the application, matching the use cases at hand.

Slide 51

Slide 51 text

Application Layer ● Defines jobs or actions that domain can do ● Coordinates lower layers ● Contains what the system should do, to satisfy a use case

Slide 52

Slide 52 text

Infrastructure Layer Wires, hardware and implementation

Slide 53

Slide 53 text

“ Consists of everything that exists independently of our application: external libraries, databases, application server, messaging backend, etc.

Slide 54

Slide 54 text

Presentation Layer How to interact with your application

Slide 55

Slide 55 text

Presentation Layer ● Interact with the application ● Patterns: MVC, MVP or MVVM

Slide 56

Slide 56 text

Presentation Layer HTML CSS JS Web Controllers Model

Slide 57

Slide 57 text

Presentation Layer Mobile Client Model Web Client API Web Controllers

Slide 58

Slide 58 text

Presentation Layer Mobile Client Model Web Client API

Slide 59

Slide 59 text

Application interaction Presentation Application Invoke actions Actions issued from Presentation are delegated to the application through commands. Normally maps to a use case.

Slide 60

Slide 60 text

Services

Slide 61

Slide 61 text

Services Services Domain Application Infrastructure

Slide 62

Slide 62 text

Services

Slide 63

Slide 63 text

Domain Service If a service makes appropriate debits and credits for an account, that capability belongs to domain layer, becoming a domain service.

Slide 64

Slide 64 text

Application Service If the banking application can convert and export transactions into a spreadsheet, that export is an application service.

Slide 65

Slide 65 text

Infrastructural Service A bank might have an application that sends an e-mail. The interface that encapsulates the email system is a infrastructure service.

Slide 66

Slide 66 text

Recommended books

Slide 67

Slide 67 text

◉ The clean architecture - 8th Light ◉ Hexagonal architecture - Alistair Cockburn ◉ Hexagonal architecture - Fideloper ◉ Hexagonal architecture - AcademyForUs (Spanish) ◉ Do you like Spaghetti or Lasagna ◉ Clean Architecture with DDD layering ◉ DDD with Symfony 2 ◉ DDD Cargo Tracker ◉ Hexagonal architecture for Java Applications Bibliography Knowledge will set you free.

Slide 68

Slide 68 text

Any questions ? Thanks!