**《Microsoft .NET 企业级应用架构设计 (第2版)》
========== ========== ==========
[作者] (意) Dino Esposito (意) Andrea Saltarello
[译者] (中) 李永伦
[出版] 人民邮电出版社
[版次] 2016年04月 第2版
[印次] 2018年05月 第5次 印刷
[定价] 69.00元
========== ========== ==========
【第01章】 【今天的架构师和架构】
(P010)
需求经由首席架构师处理之后会交由开发团队实现。
(P011)
瀑布模型已是明日黄花，你可以将它的死亡归咎于软件开发是一种工程学。
软件开发最流行的敏捷方法学是极限编程 (XP) 。
(P012)
架构师参与开发流程的所有阶段，包括需求分析和架构设计、实现、测试、集成以及部署。
架构师的主要职责是 : 确认需求，把系统分解成更小的子系统，识别和评估技术，以及制定规范。
(P013)
架构师确认需求，尽力在设计里采用和满足它们。
(P014)
架构师需要具备的一个重要特征是语言清晰。
【第02章】 【为成功而设计】
(P020)
虽然 RAD 方案对于以数据为中心的小型简单应用程序 (如 CRUD 应用程序) 来说可能刚好合适，但事实证明它对于包含大量经常改变的领域规则的大型应用程序来说是一个危险的方案。
(P024)
团队就是让在技能上互补的人们互相合作。
(P026)
好的架构师都很清楚，只有写得好的代码，对软件原则和语言特性有很好的了解，恰当使用模式和实践，以及注重可测试性才能解决代码维护的问题。这使得编码比产生刚好可以工作的代码更加昂贵，但比维护和进化刚好可以工作的代码就廉价得多了。
(P027)
代码辅助工具不是魔法，它们所做的只是让你付出更低的代价和更少的努力就可以写出更好和更干净的代码。
【第03章】 【软件设计的原则】
(P039)
OOD 的基础可以总结成以下3点 : 找出相关对象、减少接口对象之间的耦合，以及善用代码重用。
(P053)
你不选择设计模式 : 最合适的设计模式通常会在你重构的过程中浮现出来。
【第04章】 【编写优质软件】
(P061)
质量好的代码有一个基本的特点，那就是它必须是可测试的。
(P062)
代码异味会使代码变得越来越弱，找出并移除代码异味是重构的首要目标。
(P072)
领域层是最复杂的部分，也是最受需求波动影响的部分。因此，这个部分的缺陷最多。
(P079)
代码的质量通过 3 个参数来衡量 : 可测试性、可扩展性和可读性。
【第05章】 【发现领域架构】
(P083)
DDD 并不适合每个项目，因为它对技能的要求很高，而且启动成本也很高。
(P085)
关键是机会和技能，关键是所针对的上下文。
(P094)
所有逻辑层实际上都部署到某个物理层，但不同的逻辑层可能在不同的物理层。
一般而言，我们倾向于把整个应用程序栈部署到单个物理层，如果可能的话。
(P096)
应用程序层是分离表现层和领域层等接口层的绝佳方式。
应用程序层是系统后端的入口点，也是表现层和后端之间的连接点。应用程序层包含的方法几乎一一对应表现层的用例。
(P097)
应用程序负责实现应用程序的用例。它所做的就是编排任务，并把工作指派给这个栈下面的其他层。
(P098)
基础设施层的最突出组件是持久层，它就是一个传统的数据访问层，只是还可能覆盖普通关系型数据存储之外的一些数据源。持久层知道如何读取和保存数据。
【第06章】 【表现层】
(P102)
DTO 是一个类，用来携带跨越系统的逻辑层和物理层的相关数据。
用户体验不只是可视化界面设计，而用户界面是用户体验的一部分，可能仍是最重要的部分。
(P105)
理想状态下，每个屏幕应该绑到一个视图模型类，它描述了用来填充视图的数据。此外，每个屏幕应该绑到一个输入模型类，它描述了触发操作时将会离开屏幕的数据。
(P106)
MVVM 尤其适合具有强大双向数据绑定机制的应用程序场景。
就分层应用程序而言， MVC 、 MVP 和 MVVM 都是表现层的模式。
(P109)
如果 Web API 可以满足你的需求就用它，否则用 WCF 。
应用程序服务的类包含与用例一一对应的方法。
(P110)
应用程序服务可以访问这个栈下面的所有逻辑层和物理层。它可以查询和更新数据，如果有需要也可以调用外部 Web 服务。
(P113)
给网站添加一个面向设备的层是很有必要的。
(P118)
SPA 首次向服务器请求只是为了获取一些初始的 HTML 。一旦用户界面加载完毕，应用程序也完全初始化了，后续的交互就会通过 HTTP 请求上传和下载 JSON 数据来进行。
一般而言，如果你打算加入 SPA 大军，通常的原因是你想充分挖掘客户端的潜能，获得一个更好的用户体验。
(P120)
SPA 类似于部署到 Web 上的桌面应用程序。
【第07章】 【神秘的业务层】
(P124)
TS 鼓励你跳过任何面向对象设计，把你的业务组件直接映射到所需的用户操作上。
(P127)
复杂性是采用领域模型模式的驱动力。
(P130)
在 ASP.NET MVC 应用程序里，任何用户界面操作最终都会转化成控制器的类上调用的方法。
(P134)
物理层的数量原则上应该尽可能少。
(P136)
数据传输对象专门用来在不同的物理层之间携带数据。
作为一个简单容器，使用 DTO 的原因是它允许你打包多块数据，在单次往返里传输所有数据。
DTO 与生俱来就是可序列化对象。
(P138)
正确地做事的核心理念是效率 : 以优化的方式实现任务，快速且流畅。
做正确的事的核心理念是效益和达成目标。
【第08章】 【领域模型导论】
(P144)
领域层的目标和结构 : 领域模型、模块和领域服务。
DDD 模块就像 .NET 命名空间，用来组织类库项目里的类。
(P145)
值对象只是聚合在一起的数据；实体通常由数据和行为组成。
【第14章】 【持久层】
(P264)
持久层通常会创建成类库、被领域层 (特别是领域服务) 和应用程序层引用。持久层可以引用任何用于访问数据的技术，不管是 Entity Framework 或 NHibernate 等 对象 / 关系 映射 (O/RM) 、 ADO.NET 、 NoSQL 数据库，还是外部数据服务。
(P271)
IQueryable 接口并不负责查询的实际执行。它所做的只是描述要执行的查询。执行查询和构建结果是 LINQ 提供者的任务。
**