evolutionary-architecture-by-example：用故事线讲清 .NET 架构取舍
项目速览：这本 .NET 架构实践指南，通过实例解释模块化单体、微服务、领域驱动设计与常用架构模式在系统演进中的配合方式。
秒懂
- 它是什么？
- 这个仓库不是又一个模式合集，而是一套按章节推进的 .NET 架构演进教程。它用 Fitness 领域案例串联模块化单体、微服务和 DDD，直接回应“架构决策依赖上下文”这句空话。
- 适合谁用？
- 适合正在从单体向模块化过渡的 .NET 团队，尤其是那些厌倦了“Clean Architecture 万能论”的开发者。不适合期望拿到可直接部署的生产代码的人，仓库定位是教学叙事，不是脚手架。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 14 天前。
- 用什么语言写的？
- 主要是 C#（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是“架构教材脱离现实”的问题
大多数 .NET 架构资源只讲一种理想方案，要么 Clean Architecture，要么微服务，要么模块化单体。这个仓库直接指出这种做法的毛病：每种模式都被包装成普适答案，但真实项目里你需要的是组合与切换。作者用 Fitness 领域作为贯穿案例，把架构决策写成一条演进故事线，而不是静态的模式罗列。它明确承认“it depends”这句老话，但试图把模糊的依赖关系转成可操作的启发式规则。目标读者是那些已经见过多种架构、却缺少决策地图的中级 .NET 工程师。
四章故事线如何模拟真实项目演进
仓库按章节推进，第一章从单个 Fitnet 项目开始，强调垂直切片：每个业务过程一个命名空间，比如 SignContract，所有相关代码放在一起。模块之间通过简单的内存队列通信，刻意避免过度设计。第二章转向模块分离，重点是可维护性，这时你会看到模块边界如何被强化。后续章节逐步引入微服务和 DDD 的战术模式，但每一步都基于前一章的约束，而不是一次性堆砌。这种结构模仿了项目的自然演变：先跑通，再拆分，最后才考虑分布式。它把“项目悖论”摆在台面上，即项目开始时领域理解最浅，却要做最重要的架构决定。
技术栈与刻意省略的部分
后端实现基于 .NET 的 minimal API，这是仓库明确给出的技术选型。前端技术被有意排除在外，留给读者自行选择 React、Vue 或 Angular。日志推荐 Serilog，契约测试建议 Pact Net，但这两项都不是仓库内置内容。这种省略是刻意的，目的是让架构讨论不被具体前端框架或日志库绑架。仓库还包含架构决策日志，这是演进过程中记录每个重要决策及其理由的机制。如果你想知道某个模块为什么用内存队列而不是消息队列，答案应该在 ADR 里。
运行与阅读：从克隆到理解
README 没有给出具体的 dotnet run 命令，但仓库结构表明这是一个标准 .NET 解决方案，克隆后可以用 Visual Studio 或 dotnet CLI 打开。每个章节有自己的 README.adoc 文件，比如 Chapter-1-initial-architecture/README.adoc，阅读时应从这些文件入手，而不是直接翻代码。仓库还提供了一个 IcePanel 交互式链接，用于可视化第一章的架构图，这对理解模块边界有帮助。注意，这不是一个库或框架，没有 NuGet 包，也没有 API 文档，它的“运行”方式就是打开源码跟着章节读。
局限：教程叙事不等于生产模板
最大的限制是它刻意简化。内存队列作为模块间通信方式，在真实分布式系统中几乎不可能满足要求，但作者有意选择它来避免过早引入基础设施。这意味着你不能把第一章的代码直接当作生产架构的蓝本。另一个问题是，仓库覆盖的主题太多，从 DDD 战略设计到微服务拆分，每个主题的深度都有限。如果你已经在实践中用过 DDD，可能会觉得战术模式部分只是蜻蜓点水。反过来，如果你是完全的新手，第一章的垂直切片概念可能需要额外补充才能理解为什么不用传统的 Controllers 和 Services 文件夹。
与同类资源的本质区别
常见的 .NET 架构示例仓库，比如各种 Clean Architecture 模板，通常提供一个固定的项目结构，然后让你照着填代码。这个仓库相反，它展示结构如何随需求变化。Clean Architecture 模板把依赖规则固化在项目层中，而这里的垂直切片把业务过程作为组织单元，层与层之间的关系由案例故事驱动。另一个对比是微服务示例，那些仓库往往预设了服务拆分边界，而这个仓库让你看到拆分决策发生在第二章之后，基于模块间的耦合度判断。这种“先单体后拆分”的路径，比直接给一个微服务骨架更贴近真实演进。
维护状态与许可证
仓库最后一次推送是 2025 年 5 月，发布了 v1.2.0，说明作者仍在维护。MIT 许可证意味着你可以自由使用、修改和分发代码，甚至用于商业项目，但要注意代码本身是教学示例，没有提供任何担保。维护成本方面，由于内容以章节和 ADR 为主，更新节奏取决于作者何时增加新章节或修订现有案例。如果你 fork 它作为内部培训材料，需要自行跟踪上游变化，因为仓库没有提供自动更新机制。整体来看，这是一个低维护成本的参考资源，而不是一个需要持续依赖的运行时组件。
编辑结论
适合正在从单体向模块化过渡的 .NET 团队，尤其是那些厌倦了“Clean Architecture 万能论”的开发者。不适合期望拿到可直接部署的生产代码的人，仓库定位是教学叙事，不是脚手架。也不适合完全不懂 DDD 的初学者，第一章虽然从零开始，但战术模式术语出现得较快。采用前先确认两件事：第一，你是否接受垂直切片命名空间而非传统分层；第二，你的团队是否愿意维护一份架构决策日志，因为仓库把 ADR 当作演进的核心载体。若这两点与你的工作习惯冲突，这个仓库的参考价值会大打折扣。
社区笔记