Software Architecture Journey

A journey through architecture

Transcript

1. Software Architecture journey @alexsimonescu
2. Software Architecture with a taste of Clean, Hexagonal and DDD
3. Why?
4. Why we want a architecture? • Unified code style • Unified code structure • Stable platform • Fast development • Tell me yours!! Milanuncios Dev Team
5. Why to think about architecture?
6. Trends Names change but principles and goals are always the same.
7. What • Goals ◦ Software architecture goals ◦ Stakeholders goals • Clean architecture • Hexagonal • Architecture layers and DDD
8. Architecture goals • Independent of frameworks • Testable • Independent of UI • Independent of database • Independent of any external agency Robert C. Martin (Uncle Bob)
9. Some product goals • Scalable • New features • Fast bug fixing • Maybe support pivot Alexandru Simonescu
10. Software architecture evolution Lasagna-Oriented Architecture (aka Layered Monolith) Spaghetti-Oriented Architecture (aka Copy & Paste) Ravioli-Oriented Architecture (aka Microservices)
11. Software architecture evolution Lasagna-Oriented Architecture (aka Layered Monolith) Spaghetti-Oriented Architecture (aka Copy & Paste) Ravioli-Oriented Architecture (aka Microservices) What’s next?
12. Software architecture evolution Lasagna-Oriented Architecture (aka Layered Monolith) Spaghetti-Oriented Architecture (aka Copy & Paste) Ravioli-Oriented Architecture (aka Microservices) Pizza-Oriented Architecture?
13. Our plan? Monolithic Microservices
14. If you can’t build a well-structured monolith, what makes you think microservices is the answer?
15. Hexagonal Architecture
16. “ A.K.A.: Ports and Adapters
17. “ “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
18. Key concepts Ports are interfaces Adapters are implementations
21. Domain Application Framework
22. Clean Architecture
23. “ A.K.A.: Onion Architecture Uncle Bob
24. Clean architecture principles • Independent of frameworks • Testable • Independent of UI • Independent of database • Independent of any external agency
25. 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
26. 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 Core
27. 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 Core Onion Architecture
28. Domain Driven Design
29. “ 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
30. 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”
31. 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”
32. Ubiquitous Language It’s a shared jargon between domain experts and developers, based on domain model. Eric Evans, “Domain Driven Design”
33. DDD Building Blocks
34. Entity An object with clear identity and a lifecycle with state transitions that we care about.
35. Value Object An object that contains attributes but has no conceptual identity. They should be treated as immutable.
36. Value Object A small simple object, like money or a date range, whose equality isn’t based on identity. Martin Fowler
37. Anemic Domain Model Both Entity and Value Object should have data and behaviours.
38. 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
39. Aggregate A DDD aggregate is a cluster of domain objects that can be treated as a single unit. Martin Fowler
40. Domain Event Captures the memory of something interesting which affects the domain. Martin Fowler
41. N - Layer Architecture
42. “ Just because someone created and named some layers doesn’t mean your application should have them.
43. “ You should create layers AFTER you created substantial amount of code which you grouped together for sake of communication and to clarify code.
44. Layers vs Tiers Presentation Layer Business Layer Data Access Layer Crosscutting Layer Core Core DB DB Front Front
45. Layers Presentation Layer Application Layer Data Access Layer Crosscutting Layer Domain Layer Database API Persistence Infrastructure
46. Layers interaction Controllers User Interface Application Domain Infrastructure Views
47. Domain Layer The heart
48. Domain Layer The domain layer is the heart of the software, and this is where the interesting stuff happens.
49. Application Layer What your application does
50. “ The application layer is responsible for driving the workflow of the application, matching the use cases at hand.
51. Application Layer • Defines jobs or actions that domain can do • Coordinates lower layers • Contains what the system should do, to satisfy a use case
52. Infrastructure Layer Wires, hardware and implementation
53. “ Consists of everything that exists independently of our application: external libraries, databases, application server, messaging backend, etc.
54. Presentation Layer How to interact with your application
55. Presentation Layer • Interact with the application • Patterns: MVC, MVP or MVVM
56. Presentation Layer HTML CSS JS Web Controllers Model
57. Presentation Layer Mobile Client Model Web Client API Web Controllers
58. Presentation Layer Mobile Client Model Web Client API
59. Application interaction Presentation Application Invoke actions Actions issued from Presentation are delegated to the application through commands. Normally maps to a use case.
60. Services
61. Services Services Domain Application Infrastructure
62. Services
63. Domain Service If a service makes appropriate debits and credits for an account, that capability belongs to domain layer, becoming a domain service.
64. Application Service If the banking application can convert and export transactions into a spreadsheet, that export is an application service.
65. Infrastructural Service A bank might have an application that sends an e-mail. The interface that encapsulates the email system is a infrastructure service.
66. Recommended books
67. ◉ 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.
68. Any questions ? Thanks!