实现领域驱动设计 读书笔记 1-3章
前言
大事拆分为小事，小事抓住重要事，重要事中做好基础事，基础事中坚持规矩办事。——于18年2月杭州滨江出差时记
最近换了一个项目在做，有用到ddd架构，由此结缘ddd，遂看了些书以作深入理解
1.DDD架构分层
2.DDD架构中涉及的概念
3.上下文映射图
一、DDD架构分层
DDD 即DOMAIN-DRIVEN DESIGN，领域驱动设计。
主要分为四层（表现层、应用层、领域层和基础层）：
- Presentation Layer：表现层，负责展现用户信息以及解释用户命令；
- Application Layer(Service)：应用层，WCF服务，负责协调领域层的调用，向UI层提供接口，很薄的一层，只包含工作流控制逻辑，不包含业务逻辑；。
- Domain Layer(Domain)：领域层，负责表达业务概念，业务状态信息以及业务规则，即领域实体和领域逻辑；
- Infrastructure Layer：基础设施层，为其他层提供通用的技术能力，提供了层间的通信，为领域层提供持久化机制等；
在dax.net系列中的一幅图说明架构分层：
UI层同过WCF服务调用应用层的WCF接口，WCF服务通过仓储调用领域层里面的接口，基础设施层贯穿其它各层，在其他需要使用的项目中都可以引入基础设施层。
二、DDD架构中涉及的概念
领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。
领域服务：领域模型主张把领域逻辑尽量写在领域实体里面（“充血模式”），而领域服务则是用来处理领域模型里不好定义或者某些可变逻辑的时候才会用到。
领域（Domain）：即是一个组织所做的事情以及其中所包含的一切。
子域：一个领域被分为若干个子域，领域模型在限界上下文中完成开发。
限界上下文：是一个显式边界，领域模型便存在于边界之内。在边界之内，通用语言的所有术语和词组都有特定的含义，而模型需要准确的反映通用语言。
实体：在领域驱动设计里面，实体是模型中需要区分个体的对象。ddd概念里实体包含实体数据（如EF的Model）和行为的结合体。
值对象：通过对象属性值来区别的对象，它将相关属性组合为一个概念整体。值对象与实体的区别：（1）实体拥有唯一的标识，而值对象没有；（2）实体允许变化，而值对象不允许变化（3）判断两个实体相等的方法是判断实体的标识相等，而判断两个值对象的标准是值对象内部所有属性值相等；
聚合（以及聚合根）：聚合表示一组领域对象（包括实体和值对象），用来表述一个完整的领域概念。而每个聚合都有一个根实体，这个根实体又叫做聚合跟。举个简单的例子，一个电脑包含硬盘，CPU,内存条等，这一个组合就是一个聚合，而电脑就是这个组合的聚合根。同一个实体在不同的聚合中，可能是聚合根，也可能不是，根据实际业务而定。聚合根是聚合所表述的领域概念的主体，外部对象需要访问聚合内的实体时，只能通过聚合根进行访问，而不能直接访问。
仓储：作为领域层和基础结构层的连接组件，使得领域层不必过多关注存储细节。在设计时，仓储接口放在领域层，而将仓储的具体实现放在基础设施层，领域层通过接口访问数据存储，而不必过多关注仓储存储的细节（也就是说领域层不必关心用的EntityFrameWork还是NHibernate来存储数据），使得领域层将更多的关注点放在领域逻辑上面。解耦了领域层和ORM之间的关系。
三、上下文映射图
上下文映射图，画一个简单的框图来表示两个或多个限界上下文之间的映射关系。
开放主机服务（Open Host Service）定义一种协议，让你的子系统通过该协议来访问你的服务。可以看成是远程过程调用（RemoteProcedureCall，RPC）的API。也可以通过消息机制实现。
发布语言（Published Language）在两个限界上下文之间翻译模型需要一种公用的语言，通过发布出来的共享语言完成集成交流。发布语言可用于事件驱动架构，其中领域事件以消息的形式发送到订阅方。
防腐层（Anticorruption Layer）根据自己的领域模型创建一个单独的层，该层作为上游系统的代理向你的系统提供功能。
参考：http://www.cnblogs.com/landeanfen/p/4816706.html
鸣谢：netfocus，fax.net。
后记：看起来都是一些乏燥无味的概念，但其实往往都是一步步累积出来的，后续随着认识深入会记录出来。
我的理解，ddd是将一个大业务拆分为无数个小的有意义的业务，然后上下层分清职责，尽最大力度减少依赖，重点在业务领域划分。架构怎么变还是离不开开篇的那句话。
附：技术需要吸收好的语言思想，广涉猎，深钻研，接受别人讲的不好地方，才会有所改进。
