领域驱动设计-读书笔记-第十一章-应用分析模式

定义

分析模式是一种概念集合，用来表示业务建模中的常见结构。它可能只与一个领域有关，也可能跨越多个领域。分析模式这个名字本身就强调了其概念本质。分析模式并不是技术解决方案，他们只是些参考，用来指导人们设计特定领域中的模型。

作用

分析模式的最大作用是借鉴其他项目的经验，把那些项目中有关设计方向和实现结果的广泛讨论与当前模型的理解结合起
来。脱离具体的上下文来讨论模型思想不但难以落地，而且还会造成分析与设计严重脱节的风险，而这一点正是MODEL-DRIVEN DESIGN坚决反对的。作者这里有点自相矛盾，一方面说分析模式，一方面又说分析模式不是模型驱动设计所倡导的。

例子

示例 账户的利息计算

用于跟踪贷款和其他有息资产的应用程序将计算所产生的利息和手续费，并跟踪借方的付款情况。夜间会有一个批处理操作提取这些数字，并传递给原来的会计系统，并标明每个账目应该过账到哪个分类账中。

痛点：这种设计虽然能工作，但使用起来却很麻烦，修改起来也很复杂，而且不易于交流沟通。

开发人员读了，《分析模式》的第6章“Inventory and Accounting”。摘抄了一些相关的内容，受到一部分启发。

开发人员根据书上的内容，产生了新思路，以下是产生的新的领域模型。

开发人员拉上领域专家一起讨论，以下是提炼的讨论的关键部分：

开发人员：我们可以在Interest Account中为每笔利息收入增加一个Entry，而不是只调整interestDueAmount。Account到 Acoount的操作我们可以放到一个Transaction内，Transaction计算出的付款和利息又联合在一起了。

领域专家：为什么要把应计项目和付款联系在一起呢？它们在会计系统中是分开过账的。Account的平账才是主要的。沿着一个一个的Entry，我们就可以查出所有的账目。应计项目（accrual）是指在一笔支出或收入发生的时候把它记录到账目中，而永远不管现金实际是何时过账的。因此，利息每天都会计算，但只有在（举例来说）月末才会支付。

关键点：他们决定为Entry创建两个子类——Payment和Accrual，因为他们发现这两个子类在应用程序中的职责稍有不同，而且都是非常重要的领域概念。但另一方面，无论Entry是因为手续费而产生的，还是因为利息产生的，其在概念和行为上都没有任何区别。它们只是出现在适当的Account中。

示例 对夜间批处理程序的深入理解

过账规则

一个账户可能用于跟踪收入，而另一个账户可能用于跟踪该收入的估税。如果我们希望系统自动更新估税总额，那么这两个账户的实现将会彼此紧密关联。在有些系统中，大部分账目都是由这些规则产生的，在这样的系统中，依赖逻辑会变得一团糟。即使是在规模不大的系统中，这样的交叉过账也会很复杂。减少这种缠杂不清的依赖的第一步是通过引入一个新对象来使这些规则明朗化。这个我司现在的做法有点类似啊，解决循环依赖的做法，就是引入另一个系统，难道真的没有其他办法吗？

总结

很多对象模型都有文献资料可查，其中有些对象模型专门用于某个行业中的某种应用，而有些则是通用模型。大部分对象模型都有助于开阔思路，但只有为数不多的一些模型精辟地阐述了选择这些模式的原理和使用的结果，而这些才是分析模式的精华所在。

参考已有文献资料，尝试应用到自己的领域场景中，并与领域专家进一步讨论，对模型进一步深入探索。