architecture

Name: architecture
Author: managedcode

461stars35forks

How to install architecture?

managedcode/dotnet-skills/architecture

$npx -y skills add managedcode/dotnet-skills --skill architecture

Installs into the current project.

Summary

Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering. USE FOR: .NET architecture choices; layer and domain boundary review; service decomposition;

Files · 1

View on GitHub

SKILL.md

1	# .NET Architecture
2
3	## Trigger On
4
5	- choosing architecture for a new or evolving .NET system
6	- reviewing layer boundaries, domain boundaries, or service decomposition
7	- deciding whether clean architecture, vertical slices, CQRS, or microservices are justified
8
9	## Workflow
10
11	1. Start from business capability boundaries and change frequency, not from a preferred diagram style.
12	2. Use simple modular monolith patterns by default, and move to microservices only when team autonomy, scale, or deployment boundaries justify the added operational cost.
13	3. Apply DDD and CQRS where business rules are genuinely complex; avoid forcing aggregates and command pipelines into CRUD-heavy code with no payoff.
14	4. Keep dependencies flowing inward when using clean architecture, but avoid creating extra projects that add ceremony without ownership clarity.
15	5. Make integration boundaries explicit: contracts, storage ownership, messaging, consistency model, and observability expectations.
16	6. Use `aspire` when local orchestration, service discovery, and developer observability are part of the architecture story.
17
18	## Deliver
19
20	- an architecture direction that matches system complexity
21	- clear project and dependency boundaries
22	- migration notes or tradeoffs when changing an existing structure
23
24	## Validate
25
26	- the proposed structure reduces rather than increases accidental complexity
27	- data ownership and integration paths are explicit
28	- the architecture is testable and operable, not just diagram-friendly
29
30	## References
31
32	- [references/patterns.md](references/patterns.md) - detailed implementations of Clean Architecture, Vertical Slices, DDD, CQRS, Modular Monolith, and Microservices with C# 12+ examples
33	- [references/anti-patterns.md](references/anti-patterns.md) - common architectural mistakes including over-abstraction, anemic domain models, premature microservices, and cargo cult patterns

People who liked this also viewed

6 picks

Type

architecture

461stars35forks

View on GitHub

How to install architecture?

managedcode/dotnet-skills/architecture

$npx -y skills add managedcode/dotnet-skills --skill architecture

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# .NET Architecture
2
3	## Trigger On
4
5	- choosing architecture for a new or evolving .NET system
6	- reviewing layer boundaries, domain boundaries, or service decomposition
7	- deciding whether clean architecture, vertical slices, CQRS, or microservices are justified
8
9	## Workflow
10
11	1. Start from business capability boundaries and change frequency, not from a preferred diagram style.
12	2. Use simple modular monolith patterns by default, and move to microservices only when team autonomy, scale, or deployment boundaries justify the added operational cost.
13	3. Apply DDD and CQRS where business rules are genuinely complex; avoid forcing aggregates and command pipelines into CRUD-heavy code with no payoff.
14	4. Keep dependencies flowing inward when using clean architecture, but avoid creating extra projects that add ceremony without ownership clarity.
15	5. Make integration boundaries explicit: contracts, storage ownership, messaging, consistency model, and observability expectations.
16	6. Use `aspire` when local orchestration, service discovery, and developer observability are part of the architecture story.
17
18	## Deliver
19
20	- an architecture direction that matches system complexity
21	- clear project and dependency boundaries
22	- migration notes or tradeoffs when changing an existing structure
23
24	## Validate
25
26	- the proposed structure reduces rather than increases accidental complexity
27	- data ownership and integration paths are explicit
28	- the architecture is testable and operable, not just diagram-friendly
29
30	## References
31
32	- [references/patterns.md](references/patterns.md) - detailed implementations of Clean Architecture, Vertical Slices, DDD, CQRS, Modular Monolith, and Microservices with C# 12+ examples
33	- [references/anti-patterns.md](references/anti-patterns.md) - common architectural mistakes including over-abstraction, anemic domain models, premature microservices, and cargo cult patterns

People who liked this also viewed

6 picks

Type