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

More info at: https://dotnetday.ch

Transcript

1. The What. The Why. The How. EVOLUTIONARY ARCHITECTURE Maciej "MJ" Jedrzejewski
2. “Okay, we have applied the architecture, and from now on, we no longer need to care about it.”
3. “Okay, we have applied the architecture, and from now on, we no longer need to care about it.”
4. 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
5. Master Software Architecture: A Pragmatic Guide
6. Project Paradox
7. Too trivial If caught early enough, the impact will not be as great as in the case of overengineered architecture. Common issues
8. 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
10. Evolutionary Architecture
11. Simplicity Our main goal is to deliver fast results, not a fancy code. Steps of evolution
12. 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.
13. 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.
14. 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.
15. choose an architecture based on your current needs and context. Not a wishful thinking.
16. Case: Fitness Studio
17. MVP features Pass/Carnet registration Pass expiration Offer preparation Contract preparation Contract signing Passes per month reporting
18. Team 2 juniors, 2 mids, 2 seniors Experienced in .NET Lack of experience in distributed systems
19. Passes Offers Contracts Reports Highly-cohesive areas Register Pass Mark Pass As Expired Prepare Offer Prepare Contract Sign Contract Generate New Passes Per Month
20. Passes Offers Contracts Reports Flow between areas Register Pass Mark Pass As Expired Prepare Offer Prepare Contract Sign Contract Generate New Passes Per Month
21. Passes Offers Contracts Reports Flow between areas Register Pass Mark Pass As Expired Prepare Offer Prepare Contract Sign Contract Generate New Passes Per Month
22. Chapter 1: Focus on simplicity
23. 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
24. Single deployment unit Multiple deployment units Deployment strategy
25. Single deployment unit Multiple deployment units Deployment strategy
26. Single Production Code Project Solution structure
27. Single Production Code Project Solution structure Tests Project(s)
29. Passes Offers Contracts Reports Namespaces
30. Architecture tests (ArchUnitNET, NetArchTest)
32. https://github.com/BenMorris/NetArchTest
33. Architecture tests Solution structure
34. Passes Offers Contracts Reports Namespaces Database
35. Passes Offers Contracts Reports Namespaces Database Passes Schema
36. Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema
37. Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema Contracts Schema
38. Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema Contracts Schema
39. Communication Module A Module B Module C
40. Communication Module A Module B Public API references Module C
41. Communication Module A Module B Public API references Module C sends event to In-memory queue reads event from
42. Chapter 2: Focus on maintainability
43. 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
44. Single deployment unit Deployment strategy
45. Solution structure Passes Projects Offers Projects Contracts Projects Reports Projects
46. Solution structure Passes Projects Offers Projects Contracts Projects Reports Projects Building Blocks Projects
48. Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema
49. Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema Contracts Database
50. Passes Offers Contracts Reports Namespaces Database Passes Schema Offers Schema Contracts Database
51. Modular Monolith Instance Database
52. Modular Monolith Instance 1 Database Modular Monolith Instance 2
53. Modular Monolith Instance 1 Database Modular Monolith Instance 2 Load Balancer
54. Modular Monolith Instance 1 Database Database Replica Modular Monolith Instance 2 Load Balancer
55. Modular Monolith Instance 1 Database Database Replica Database Replica Modular Monolith Instance 2 Load Balancer
56. Modular Monolith Instance 1 Database Database Replica Database Replica Modular Monolith Instance 2 Load Balancer Cache
57. Chapter 3: Focus on growth
58. 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
59. Single deployment unit Multiple deployment units Deployment strategy
60. Solution structure Passes Projects Offers Projects Reports Projects Modular Monolith
61. Solution structure Passes Projects Offers Projects Contracts Projects Reports Projects Modular Monolith Microservice
62. Solution structure Passes Projects Offers Projects Contracts Projects Reports Projects Building Blocks Projects Modular Monolith Nuget Packages Microservice
63. Communication Module A Module B Public API references Module C
64. Communication Module A Module B Public API references Module C Microservice
65. 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
66. Modular Monolith Instance 1 Database Database Replica Modular Monolith Instance 2 API Gateway + Load Balancer Cache Microservice Microservice Database
67. Chapter 4: Focus on complexity
68. Assumptions Business logic in Contracts becomes extremely complex Team complains about its maintainability
69. 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
71. Summary Start as simple as possible
72. Summary Start as simple as possible Evolve pragmatically
73. Summary Start as simple as possible Evolve pragmatically Shift technical decisions
74. Summary Start as simple as possible Evolve pragmatically Shift technical decisions Fit architecture to your current needs
75. Summary Start as simple as possible Evolve pragmatically Shift technical decisions Fit architecture to your current needs Businesses change!
77. Repo Book Thank you for listening!