前言
我们写这本书的主要目的是为你带来一个关于软件架构的坚实、可重用以及易于访问的知识库。在过去，我们使用Microsoft Windows DNA、分布式COM、多层CRUD、SOA、DDD、CQRS和事件溯源等技术完成了很多项目。我们用过Microsoft Visual Basic 6、C#、C++、Java和JavaScript。我们目睹了技术解决方案不断改变，对于这些方案的看法也进化了。
最终，我们和Fred Brooks得出的结论相同。我们不穿白袍，我们不是医生，我们不写处方。我们在这里的目的是汇聚各方观点，加入我们对这些观点的见解和评论，如实地总结这些事实和看法。
当开发者和架构师被要求立刻采取正确的方案时，我们提供一个知识快照——现成的软件架构师心得，可以用作进一步研究的起点，也可以用来形成你自己的判断。如果软件架构是一个定理，（我们希望）这本书将会提供一些必要的引理。
软件架构有一些前置条件（设计原则）和一个后置条件（实现一个产生预期结果的系统）。本书的第1部分是“基础”，为软件架构打下基础，关注架构师的角色、软件项目的固有机制以及提升软件品质方面，如可测试性和可读性。
第2部分是“设计架构”，关注构成典型企业系统的最上面两层：表现层和业务层。我们把标准的第3层放在后面：数据访问层。我们推行一个比较新的系统设计方案，叫作用户体验优先。它是一个基于任务的方法学，从达成共识的模型和屏幕引出命令和领域事件。就基于任务的设计理念而言，领域模型的角色不再是中心，数据访问层也只是基础设施的一部分了，而且不一定基于标准的关系型表。第2部分最给力的一章是第5章“发现领域架构”，我们推荐所有人阅读。简而言之，这章的观点是只有深刻理解领域才能发现合适架构。更重要的是，结果架构不一定是适用于整个应用程序的单个顶层架构。当识别出子领域时，你可以把它们建模成子应用程序，给予每个最有效的架构。听起来可能有点奇怪，但这就是领域驱动设计（DDD）的要旨。
第3部分是“支撑架构”，涵盖3个可以用来构建各种子领域的支撑架构。每个架构都有两章——介绍和实现。我们考虑的第一个支撑架构是领域模型。接着，我们会讲命令/查询责任分离（CQRS）和事件溯源。
最后，第4部分“基础设施”，只包含一章，它处理基础设施和持久层。有趣的是，这章不仅仅讲到SQL、Entity Framework和关系型数据库，还着重讲了多样化和持久化、NoSQL数据存储和用来隐藏存储细节的服务。
那么，这本书到底是关于什么的？
这是关于在.NET平台上更好地满足你的客户需要知道和做到什么的一本书。我们给出的模式、原则和技术一般来说都是有效的，并非针对复杂的行业系统。一个好的软件架构可以帮助控制项目的复杂性。控制复杂性和支持可维护性是我们应对技术领域的墨菲定理的最好策略：“没有什么能按时、按预算构建出来。”为了做到这点，只有一件事情是不允许失败的：（深刻）理解业务领域。
目录
第1部分 基础
第1章 今天的架构师和架构
1.1 软件架构到底是什么
1.1.1 把架构原则应用到软件中
1.1.2 确认需求
1.1.3 什么是架构，什么不是
1.1.4 架构流程
1.2 谁是架构师
1.2.1 架构师的职责
1.2.2 架构师的角色
1.2.3 关于架构师的常见误解
1.3 总结
1.4 笑到最后
第2章 为成功而设计
2.1 “大泥球”
2.1.1 “大泥球”的成因
2.1.2 “大泥球”的征兆
2.1.3 使用指标检测BBM
2.2 软件项目的机制
2.2.1 组织文化
2.2.2 帮助团队更好地写代码
2.3 走出混乱
2.3.1 有一种奇怪的东西叫作“遗留代码”
2.3.2 在3招之内将杀（checkmate）
2.3.3 决定是否添加人手
2.4 总结
2.5 笑到最后