Upgrade to Pro — share decks privately, control downloads, hide ads and more …

.NET Day 2024: Evolutionary Architecture. The W...

dotnetday
September 11, 2024

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

More info at: https://dotnetday.ch

dotnetday

September 11, 2024
Tweet

More Decks by dotnetday

Other Decks in Technology

Transcript

  1. “Okay, we have applied the architecture, and from now on,

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

    we no longer need to care about it.”
  3. 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
  4. Too trivial If caught early enough, the impact will not

    be as great as in the case of overengineered architecture. Common issues
  5. 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
  6. 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.
  7. 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.
  8. 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.
  9. Team 2 juniors, 2 mids, 2 seniors Experienced in .NET

    Lack of experience in distributed systems
  10. Passes Offers Contracts Reports Highly-cohesive areas Register Pass Mark Pass

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

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

    Pass As Expired Prepare Offer Prepare Contract Sign Contract Generate New Passes Per Month
  13. 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
  14. Communication Module A Module B Public API references Module C

    sends event to In-memory queue reads event from
  15. 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
  16. 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
  17. Solution structure Passes Projects Offers Projects Contracts Projects Reports Projects

    Building Blocks Projects Modular Monolith Nuget Packages Microservice
  18. 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
  19. Modular Monolith Instance 1 Database Database Replica Modular Monolith Instance

    2 API Gateway + Load Balancer Cache Microservice Microservice Database
  20. 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
  21. Summary Start as simple as possible Evolve pragmatically Shift technical

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

    decisions Fit architecture to your current needs Businesses change!