Back to Details

architecture

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

.NET Architecture

.NET架构

Trigger On

触发场景

  • choosing architecture for a new or evolving .NET system
  • reviewing layer boundaries, domain boundaries, or service decomposition
  • deciding whether clean architecture, vertical slices, CQRS, or microservices are justified
  • 为新的或演进中的.NET系统选择架构
  • 评审层边界、域边界或服务拆分方案
  • 判断是否适合采用clean architecture、vertical slices、CQRS或microservices

Workflow

工作流程

  1. Start from business capability boundaries and change frequency, not from a preferred diagram style.
  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.
  3. Apply DDD and CQRS where business rules are genuinely complex; avoid forcing aggregates and command pipelines into CRUD-heavy code with no payoff.
  4. Keep dependencies flowing inward when using clean architecture, but avoid creating extra projects that add ceremony without ownership clarity.
  5. Make integration boundaries explicit: contracts, storage ownership, messaging, consistency model, and observability expectations.
  6. Use 
    aspire
    when local orchestration, service discovery, and developer observability are part of the architecture story.
  1. 从业务能力边界和变更频率出发，而非偏好的图表风格。
  2. 默认采用简单的modular monoliths模式，仅当团队自治、规模或部署边界能抵消额外运维成本时，才转向microservices。
  3. 在业务规则真正复杂的场景应用DDD和CQRS；避免将聚合和命令管道强行套用到以CRUD为主的代码中，无实际收益。
  4. 使用clean architecture时保持依赖向内流动，但避免创建额外项目，增加形式化流程却不明确职责归属。
  5. 明确集成边界：契约、存储所有权、消息传递、一致性模型和可观测性预期。
  6. 当本地编排、服务发现和开发者可观测性是架构需求的一部分时，使用
    aspire
    。

Deliver

交付成果

  • an architecture direction that matches system complexity
  • clear project and dependency boundaries
  • migration notes or tradeoffs when changing an existing structure
  • 匹配系统复杂度的架构方向
  • 清晰的项目和依赖边界
  • 变更现有架构时的迁移说明或权衡分析

Validate

验证标准

  • the proposed structure reduces rather than increases accidental complexity
  • data ownership and integration paths are explicit
  • the architecture is testable and operable, not just diagram-friendly
  • 提议的架构能减少而非增加偶发复杂度
  • 数据所有权和集成路径清晰明确
  • 架构具备可测试性和可操作性，而非仅适合绘制图表

References

参考资料

  • references/patterns.md - detailed implementations of Clean Architecture, Vertical Slices, DDD, CQRS, Modular Monolith, and Microservices with C# 12+ examples
  • references/anti-patterns.md - common architectural mistakes including over-abstraction, anemic domain models, premature microservices, and cargo cult patterns
  • references/patterns.md - 包含Clean Architecture、Vertical Slices、DDD、CQRS、modular monoliths和microservices的详细实现，附C# 12+示例
  • references/anti-patterns.md - 常见架构错误，包括过度抽象、贫血域模型、过早microservices和盲目跟风模式