> Markdown version of [/videos/935-architectures-that-we-can-use-with-net?t=1190](https://www.wearedevelopers.com/videos/935-architectures-that-we-can-use-with-net?t=1190). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Architectures that we can use with .NET

Modern IDEs will catch syntax errors, but they won't fix bad architecture. Master modular .NET designs like Clean Architecture and targeted CQRS to build highly resilient software.

- **Speakers:** [Sommer](https://www.wearedevelopers.com/@sommer)
- **Event:** World Congress 2024
- **Published:** August 20, 2024
- **Duration:** 24:26
- **URL:** https://www.wearedevelopers.com/videos/935-architectures-that-we-can-use-with-net

## Summary

This technical overview explores practical software architecture patterns for .NET applications, presented from the perspective of an everyday developer working directly with code. The core premise establishes that while modern IDEs can automatically warn developers about syntax and naming conventions, architectural design remains a deeply manual, human-driven necessity. Building a sound architecture isolates stable core logic from frequently changing UI or database components, improves testing capabilities, and establishes a ubiquitous language that accelerates new developer onboarding. The discussion begins by acknowledging the historical legacy of traditional layered architectures, which are often found in legacy systems and suffer from excessive code duplication, before transitioning into modern modular approaches like Hexagonal (Ports and Adapters) and Onion architectures, which strictly couple dependencies toward the center.

Moving deeper into modern patterns, the evolution of 'Clean Architecture' is deconstructed as an amalgamation of Hexagonal principles, Screaming Architecture (favoring intent-revealing feature folders over generic MVC structures), and the 'East Coast Approach,' where entities possess rich behavior rather than just data. A critical warning is woven into the adoption of CQRS and libraries like MediatR: developers should 'apply CQRS only to limited sections of your system' rather than utilizing it universally, avoiding severe maintenance overhead. Furthermore, the UI layer's Presenter is highlighted as a Humble Object whose exact purpose is repackaging data into view models, a critical concept that prevents underlying database structures from leaking to the client.

The narrative concludes by examining specialized architectural styles tailored for highly performant and concurrent .NET environments. Aspect-Oriented Programming (AOP) is showcased as an ideal solution for cross-cutting concerns using ASP.NET middleware or Autofac interceptors, while Microkernel architectures are noted for utilizing AssemblyLoadContext to dynamically load and unload libraries at runtime. To resolve the inherent deadlocks and swallowed exceptions common in background thread execution, Reactive architectures and the Actor Model are introduced. By differentiating between broadcast-style event-driven architectures and targeted message-driven systems, frameworks like Akka.NET introduce profound system resilience, granting supervisor actors the intelligence to gracefully restart, resume, or terminate failing child subordinates.

**Keywords:** .NET clean architecture implementation, hexagonal ports and adapters pattern, onion architecture pattern, data context interaction sequence tasks, east coast approach rich domain models, boundary control entity usage, screaming architecture folder structures, CQRS and MediatR anti-patterns, presenter humble object data security, aspect-oriented programming interceptors, microkernel assemblyloadcontext dynamic loading, reactive message-driven vs event-driven systems, actor model akka.net multithreading, dependency injection infrastructure isolation, ubiquitous language domain-driven design

## Chapters

1. **Classification of architect roles in software development** (00:03) — Differentiating architect specialities helps developers understand which roles manage code versus platform or customer concerns.
1. **Core reasons for adopting architectural rules in projects** (01:12) — Separating stable application components from frequently changing parts makes testing and team collaboration much easier.
1. **Advantages and historical context of layered software architecture** (02:53) — While dividing logic into structured layers provides clear separation of concerns, it often leads to excessive code repetition.
1. **Combining data context interaction and east coast paradigms** (03:35) — Applying information expert patterns and context bounds improves sequence-based functionality without relying solely on atomic logic operations.
1. **Defining application constraints via boundary control entity structures** (06:08) — Using controllers directly as use cases enables clear interaction flows across separated data access points.
1. **Decoupling databases using hexagonal architecture and data ports** (07:16) — Restricting infrastructure details behind specific interface adapters ensures core application logic remains strictly independent.
1. **Isolating infrastructure implementation with onion architecture dependency flows** (08:02) — Pointing dependencies toward inner core schemas prevents user interfaces from directly querying underlying database objects.
1. **Applying cqrs and mediator patterns selectively across systems** (11:16) — Limiting command query separation strategies to specific boundary interactions prevents unnecessary duplication in simpler modules.
1. **Clarifying business intent through screaming project directory structures** (12:03) — Shaping folders around distinct application capabilities rather than abstract framework components reveals true business purpose.
1. **Injecting runtime flexibility with aspect and microkernel architectures** (18:27) — Implementing method interceptors and external assembly management allows logical decoupling and dynamic library replacement at runtime.
1. **Scaling responsive systems through reactive and message architectures** (19:50) — Differentiating message-driven approaches from pure events ensures targeted delivery scopes and horizontally scalable microservices.
1. **Resolving thread deadlocks by utilizing the actor model** (21:22) — Handling concurrent background computations through isolated supervisor objects prevents unresponsive communication states in heavily threaded applications.

## Related Moments

- [Navigating complexity and anti-patterns in modern software architecture](https://www.wearedevelopers.com/videos/874-system-resilience-surviving-the-software-storm) (from "System Resilience: Surviving the Software Storm")
- [Exploring architectural patterns and infrastructure deployment strategies](https://www.wearedevelopers.com/videos/1827-mastering-modern-architecture-oliver-sturm) (from "Mastering Modern Architecture - Oliver Sturm")
- [Applying pure core architectural patterns to web applications](https://www.wearedevelopers.com/videos/892-typed-security-preventing-vulnerabilities-by-design) (from "Typed Security: Preventing Vulnerabilities By Design")
- [Architecting the platform with modern cloud and mobile technologies](https://www.wearedevelopers.com/videos/64-shared-mobility-for-everyone) (from "Shared mobility for everyone!")
- [Summarizing architecture benefits and answering audience questions](https://www.wearedevelopers.com/videos/705-tackling-complexity-with-functional-programming-and-kotlin) (from "Tackling Complexity With Functional Programming And Kotlin")
- [Discussing pragmatic architectural scope reduction and system design patterns](https://www.wearedevelopers.com/videos/206-move-fast-with-software-architecture) (from "Move fast with Software Architecture")

## Related Articles

- [Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)](https://www.wearedevelopers.com/magazine/745-why-event-driven-architecture-isn-t-about-speed-and-when-you-actually-need-it)
- [How to Avoid Over-Engineering](https://www.wearedevelopers.com/magazine/546-how-to-avoid-over-engineering)
- [Why You Shouldn’t Build a Microservice Architecture](https://www.wearedevelopers.com/magazine/118-why-you-shouldn-t-build-a-microservice-architecture)
- [Dev Digest 139 - Soft and hard queries](https://www.wearedevelopers.com/magazine/487-dev-digest-139-soft-and-hard-queries)

## Related Jobs

- [Senior Software Engineer, Client Apps Platform](https://www.wearedevelopers.com/jobs/ext/1773893-senior-software-engineer-client-apps-platform) at **GitHub**
- [Principal Software Engineer, Enterprise AI Platform](https://www.wearedevelopers.com/jobs/ext/1467292-principal-software-engineer-enterprise-ai-platform) at **GitHub**
- [Software Solution Architekt](https://www.wearedevelopers.com/jobs/ext/1458613-software-solution-architekt) at **BWI GmbH**
- [Principal Software Engineer, Identity](https://www.wearedevelopers.com/jobs/ext/1469181-principal-software-engineer-identity) at **GitHub**
- [Backend Entwickler C#/.NET iv.)](https://www.wearedevelopers.com/jobs/ext/1262419-backend-entwickler-c-net-iv) at **Bosch-Gruppe Österreich**
- [Senior Engineer, Infrastructure Platform](https://www.wearedevelopers.com/jobs/ext/328836-senior-engineer-infrastructure-platform) at **Intercom, Inc.**