.NET Day 2024: Evolutionary Architecture. The What. The Why. The How

by .NET Day

Slide 1

Slide 1 text

The What. The Why. The How. EVOLUTIONARY ARCHITECTURE Maciej "MJ" Jedrzejewski

Slide 2

Slide 2 text

“Okay, we have applied the architecture, and from now on, we no longer need to care about it.”

Slide 3

Slide 3 text

“Okay, we have applied the architecture, and from now on, we no longer need to care about it.”

Slide 4

Slide 4 text

12+ years in IT Around 30 projects (and products) Microsoft MVP Trainer at letsboot.ch Open-source contributor Lover of Domain-Driven Design Living in Switzerland since 2021 About me Fractional Architect | Auditor | Trainer

Slide 5

Slide 5 text

Master Software Architecture: A Pragmatic Guide

Slide 6

Slide 6 text

Project Paradox

Slide 7

Slide 7 text

Too trivial If caught early enough, the impact will not be as great as in the case of overengineered architecture. Common issues

Slide 8

Slide 8 text

Too trivial If caught early enough, the impact will not be as great as in the case of overengineered architecture. Too complex Far more difficult to reverse than if the architecture is too simple. By the time this is noticed it is usually too late to make changes. Common issues

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

Evolutionary Architecture

Slide 11

Slide 11 text

Simplicity Our main goal is to deliver fast results, not a fancy code. Steps of evolution

Slide 12

Slide 12 text

Simplicity Our main goal is to deliver fast results, not a fancy code. Steps of evolution Maintainability Within time, the complexity of solution and size of team(s) grows.

Slide 13

Slide 13 text

Simplicity Our main goal is to deliver fast results, not a fancy code. Growth At some point, the growth is so fast that it makes no sense to scale and share entire application. Steps of evolution Maintainability Within time, the complexity of solution and size of team(s) grows.

Slide 14

Slide 14 text

Simplicity Our main goal is to deliver fast results, not a fancy code. Growth At some point, the growth is so fast that it makes no sense to scale and share entire application. Complexity In the end, complexity of business domain increases. It is the time to apply better fitting patterns to some parts of it. Steps of evolution Maintainability Within time, the complexity of solution and size of team(s) grows.

Slide 15

Slide 15 text

choose an architecture based on your current needs and context. Not a wishful thinking.

Slide 16

Slide 16 text

Case: Fitness Studio

Slide 17

Slide 17 text

MVP features Pass/Carnet registration Pass expiration Offer preparation Contract preparation Contract signing Passes per month reporting

Slide 18

Slide 18 text

Team 2 juniors, 2 mids, 2 seniors Experienced in .NET Lack of experience in distributed systems

Slide 19

Slide 19 text

Passes Offers Contracts Reports Highly-cohesive areas Register Pass Mark Pass As Expired Prepare Offer Prepare Contract Sign Contract Generate New Passes Per Month

Slide 20

Slide 20 text

Passes Offers Contracts Reports Flow between areas Register Pass Mark Pass As Expired Prepare Offer Prepare Contract Sign Contract Generate New Passes Per Month

Slide 21

Slide 21 text

Passes Offers Contracts Reports Flow between areas Register Pass Mark Pass As Expired Prepare Offer Prepare Contract Sign Contract Generate New Passes Per Month

Slide 22

Slide 22 text

Chapter 1: Focus on simplicity

Slide 23

Slide 23 text

Assumptions 1,000-1,500 users in the first year Each studio has different opening hours We start in Europe Each person will create about 100 requests per day Team decides for .NET 8

Slide 24

Slide 24 text

Single deployment unit Multiple deployment units Deployment strategy

Slide 25

Slide 25 text

Single deployment unit Multiple deployment units Deployment strategy

Slide 26

Slide 26 text

Single Production Code Project Solution structure

Slide 27

Slide 27 text

Single Production Code Project Solution structure Tests Project(s)

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

Passes Offers Contracts Reports Namespaces

Slide 30

Slide 30 text

Architecture tests (ArchUnitNET, NetArchTest)

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

https://github.com/BenMorris/NetArchTest

Slide 33

Slide 33 text

Architecture tests Solution structure

Slide 34

Slide 34 text

Passes Offers Contracts Reports Namespaces Database

Slide 35

Slide 35 text

Passes Offers Contracts Reports Namespaces Database Passes Schema

Slide 36

Slide 36 text

Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema

Slide 37

Slide 37 text

Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema Contracts Schema

Slide 38

Slide 38 text

Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema Contracts Schema

Slide 39

Slide 39 text

Communication Module A Module B Module C

Slide 40

Slide 40 text

Communication Module A Module B Public API references Module C

Slide 41

Slide 41 text

Communication Module A Module B Public API references Module C sends event to In-memory queue reads event from

Slide 42

Slide 42 text

Chapter 2: Focus on maintainability

Slide 43

Slide 43 text

Assumptions Each module grows Some modules change more often There is one new team Some modules are CRUDish, some complicated, while others are complex Our application is used by 7,500 people

Slide 44

Slide 44 text

Single deployment unit Deployment strategy

Slide 45

Slide 45 text

Solution structure Passes Projects Offers Projects Contracts Projects Reports Projects

Slide 46

Slide 46 text

Solution structure Passes Projects Offers Projects Contracts Projects Reports Projects Building Blocks Projects

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema

Slide 49

Slide 49 text

Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema Contracts Database

Slide 50

Slide 50 text

Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema Contracts Database

Slide 51

Slide 51 text

Modular Monolith Instance Database

Slide 52

Slide 52 text

Modular Monolith Instance 1 Database Modular Monolith Instance 2

Slide 53

Slide 53 text

Modular Monolith Instance 1 Database Modular Monolith Instance 2 Load Balancer

Slide 54

Slide 54 text

Modular Monolith Instance 1 Database Database Replica Modular Monolith Instance 2 Load Balancer

Slide 55

Slide 55 text

Modular Monolith Instance 1 Database Database Replica Database Replica Modular Monolith Instance 2 Load Balancer

Slide 56

Slide 56 text

Modular Monolith Instance 1 Database Database Replica Database Replica Modular Monolith Instance 2 Load Balancer Cache

Slide 57

Slide 57 text

Chapter 3: Focus on growth

Slide 58

Slide 58 text

Assumptions Contracts module changes more often than others Contracts module is used heavily Contracts module requires high security standards One team is fully focused on Contracts Our application is used by 100,000 people

Slide 59

Slide 59 text

Single deployment unit Multiple deployment units Deployment strategy

Slide 60

Slide 60 text

Solution structure Passes Projects Offers Projects Reports Projects Modular Monolith

Slide 61

Slide 61 text

Solution structure Passes Projects Offers Projects Contracts Projects Reports Projects Modular Monolith Microservice

Slide 62

Slide 62 text

Solution structure Passes Projects Offers Projects Contracts Projects Reports Projects Building Blocks Projects Modular Monolith Nuget Packages Microservice

Slide 63

Slide 63 text

Communication Module A Module B Public API references Module C

Slide 64

Slide 64 text

Communication Module A Module B Public API references Module C Microservice

Slide 65

Slide 65 text

Communication Module A Module B Public API references Module C sends event to Message Broker reads event from Microservice sends event to reads event from

Slide 66

Slide 66 text

Modular Monolith Instance 1 Database Database Replica Modular Monolith Instance 2 API Gateway + Load Balancer Cache Microservice Microservice Database

Slide 67

Slide 67 text

Chapter 4: Focus on complexity

Slide 68

Slide 68 text

Assumptions Business logic in Contracts becomes extremely complex Team complains about its maintainability

Slide 69

Slide 69 text

Aggregates Logical clusters of domain objects that are treated as a single unit, ensuring consistency and encapsulating business rules Value Objects Immutable domain objects that represent attributes or characteristics, which are identified by their value rather than their identity Domain Model Entities Mutable domain objects that have a unique identity and are defined by their attributes and behavior throughout their lifecycle

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

Summary Start as simple as possible

Slide 72

Slide 72 text

Summary Start as simple as possible Evolve pragmatically

Slide 73

Slide 73 text

Summary Start as simple as possible Evolve pragmatically Shift technical decisions

Slide 74

Slide 74 text

Summary Start as simple as possible Evolve pragmatically Shift technical decisions Fit architecture to your current needs

Slide 75

Slide 75 text

Summary Start as simple as possible Evolve pragmatically Shift technical decisions Fit architecture to your current needs Businesses change!