DDD及相关概念

领域：指一个具体的应用范围，比如电商、订票管理、会议管理等，实现某一领域的功能，与其对应的商业领域一致。譬如Contoso会议管理系统从两个方面来阐述（1）系统概览：销售会议座位、创建新会议【领域的活动是什么，核心内容】（2）非功能性需求：扩展性、灵活性【降低维护成本，延长生命周期】。
有界上下文：引入本概念的目的是为大型、复杂系统的分解提供一种容易管理的方法。在这种分解方式下，一个大型系统由多个有界上下文构成，每个有界上下文所包含的是一个自包容的领域模型，且有自己本身的普适语言。可以将有界上下文看做是一个有着清晰一致性边界的自动化的商业组件。在通常情况下，一个有界上下文更另一个有界上下文进行通信的方法是发送事件。
上下文线路图：描述不同模型之间的接触点，明确说明所有需要进行翻译的通信链接，并注明任何共享模块或对象。用户在进行这些活动后得出的结果就是一种“上下文线路图”。这种地图提供的是整个系统的概览，帮忙人民理解不同的有界上下文是如何相互交互的。
失血模型：模型仅仅包含数据的定义和getter/setter方法，业务逻辑和应用逻辑都放到服务层中。这种类在java中叫POJO，在.NET中叫POCO。 贫血模型：贫血模型中包含了一些业务逻辑，但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出，贫血模型中的领域对象是不依赖于持久层的。 充血模型：充血模型中包含了所有的业务逻辑，包括依赖于持久层的业务逻辑。所以，使用充血模型的领域层是依赖于持久层，简单表示就是 UI层->服务层->领域层<->持久层 胀血模型：胀血模型就是把和业务逻辑不想关的其他应用逻辑（如授权、事务等）都放到领域模型中。我感觉胀血模型反而是另外一种的失血模型，因为服务层消失了，领域层干了服务层的事，到头来还是什么都没变。 实体： 值对象： 聚合： 上下文： 函数式编程： 函数式编程三大思想：
immutable data 不可变数据：像Clojure一样，默认上变量是不可变的，如果你要改变变量，你需要把变量copy出去修改。这样一来，可以让你的程序少很多Bug。因为，程序中的状态不好维护，在并发的时候更不好维护。（你可以试想一下如果你的程序有个复杂的状态，当以后别人改你代码的时候，是很容易出bug的，在并行中这样的问题就更多了）

first class functions：这个技术可以让你的函数就像变量一样来使用。也就是说，你的函数可以像变量一样被创建，修改，并当成变量一样传递，返回或是在函数中嵌套函数。这个有点像Javascript的Prototype。

尾递归优化：我们知道递归的害处，那就是如果递归很深的话，stack受不了，并会导致性能大幅度下降。所以，我们使用尾递归优化技术——每次递归时都会重用stack，这样一来能够提升性能，当然，这需要语言或编译器的支持。Python就不支持。

函数式编程的技术：
map & reduce ：这个技术不用多说了，函数式编程最常见的技术就是对一个集合做Map和Reduce操作。这比起过程式的语言来说，在代码上要更容易阅读。（传统过程式的语言需要使用for/while循环，然后在各种变量中把数据倒过来倒过去的）这个很像C++中的STL中的foreach，find_if，count_if之流的函数的玩法。
pipeline：这个技术的意思是，把函数实例成一个一个的action，然后，把一组action放到一个数组或是列表中，然后把数据传给这个action list，数据就像一个pipeline一样顺序地被各个函数所操作，最终得到我们想要的结果。
recursing 递归 ：递归最大的好处就简化代码，他可以把一个复杂的问题用很简单的代码描述出来。注意：递归的精髓是描述问题，而这正是函数式编程的精髓。
currying：把一个函数的多个参数分解成多个函数， 然后把函数多层封装起来，每层函数都返回一个函数去接收下一个参数这样，可以简化函数的多个参数。在C++中，这个很像STL中的bind_1st或是bind2nd。
higher order function 高阶函数：所谓高阶函数就是函数当参数，把传入的函数做一个封装，然后返回这个封装函数。现象上就是函数传进传出，就像面向对象对象满天飞一样。

Event Source： 事件源
基于事件源解决方案的核心要素是：

（1）在aggregate实例的状态发生变化时，该实例将发起一个事件来完整描述此种状态变化。

（2）系统将这些发生事件保存在一个事件库里面。

（3）aggregate可以通过重播过去的事件流来重建自己的状态。[在对系统的错误进行分析时，事件源和事件重播真是无价的。例如，我们可以首先在本地复制一个事件库，然后在本地重播事件流来对应用程序进行调试，并理解到底在生产系统里面发生了什么事情。]

（4）其他aggregate和流程管理器（可能位于不同的有界上下文里）可以订购这些事件。

CQRS： Command Query Responsibility Segregation 命令查询职责分离模式 自洽：自洽是操作的一种特性，意味着该操作能够应用多次而不改变结果。例如，“将变量x的值设置为10”就是一个自洽操作，而“在x的值上面加1”则不是自洽操作。在消息传递环境中，如果一条消息可以传递多次而不会改变结果，则该消息是自洽的。消息自洽的原因有两个：有可能是消息本身的性质使然，也有可能是系统处理消息的方法使然。【来自：探索CQRS和事件源.pdf 第137页】