DDD 与 EDA- 核心逻辑提炼方法论

在【DDD与应用架构】一文中我们说过，应用架构的存在就是为了把一团混沌的代码变得有秩序，好管理。我们保持最核心逻辑不变，就可以保持系统的稳定与发展。领域驱动设计的作者 Eric Evans 说：“为了使领域模型成为有价值的资产，必须整齐地梳理出模型的真正核心，并完全根据这个核心来创建应用程序的功能”。那么问题来了，我们要怎么梳理出模型的真正核心呢？Eric 是这么说的:

“对模型进行提炼。找到 CORE DOMAIN 并提供一种易于区分的方法把它与那些起辅助作用的模型和代码分开。最有价值和最专业的概念要轮廓分明。尽量压缩 CORE DOMAIN。让最有才能的人来开发 CORE DOMAIN，并据此要求进行相应的招聘。在 CORE DOMAIN 中努力开发能够确保实现系统蓝图的深层模型和柔性设计。仔细判断任何其他部分的投入，看它是否能够支持这个提炼出来的 CORE。”摘录来自领域驱动设计：软件核心复杂性应对之道[美] 埃里克 埃文斯（Eric Evans）

这里我必需提一下 Eric 说的上下文，避免造成误会。Eric 说这段话是说大部分优秀的开发人员都去进行基础设施建设了，而能力差的那些常常会去设计数据库，无休止的进行 CURD。我个人比较赞同这种观点。领域设计可能需要大家在观念上有所转变，现在大多数开发都属于业务开发，业务开发最重要的不是说对一些基础设施了解的有什么深入，而是应该对你所属的行业了解到一定程度，能够刻画你所属的行业的核心业务逻辑。这里不是说搞明白基础设施不重要，而是现有的软件开发基础设施已经比较完善，借助于分布式，中间件，很多公司的开发人员都能构建一个比较可靠的秒杀系统了，高并发、大流量这些前些年听起来很酷炫的技能现在可能随处可见。而业务人员未来的竞争力可能会在于对某种垂直行业的认知，而这些认知，能帮助你成为 Eric 文中有才能的人。当然，成为真正有才能的人，可能还需要了解一些方法论，帮助你更好的刻画领域。

看待问题的角度

场景一：

西风公司的数据智能部门需要对公司楼下的早餐店进分析，想看看公司在餐饮行业有没有机会。于是派了公司的两个数据大佬西哥与风哥去调研。一天之后，西风与风哥分别分享了自己的调查情况。

西哥的调研报告

5:30AM 早餐店门打开了 6:00AM 包子蒸好了 6:10AM 豆浆做好了 6:30AM 包子出售了 10 个，豆浆出售了 20 个。支付宝收到金额 35 元，支付收到金额 25 元。。。。。

风哥的调研报告

老板与老板娘两个人一大早打开了早餐店，并且开始蒸包子，做豆浆。做蒸包子的时候，老板娘又去门口把今天包子与豆浆的易拉宝上。易拉宝上记录着今天早餐店的优惠价格。早的时候，大部分都是楼旁边小区的居民出来买，居民们大多时候都是慢慢悠悠的走过来，包子豆浆一块买，老人家一般会自带盆，让老板把早餐装盆里，有些还会坐在店里吃。快到上班的时候，很多白领会跑着过来，快速的选择已经打包好的组合套餐，拎着就往楼上跑。。。

场景二：

小西与小风都是艾薇儿的忠实粉丝，一天，小西与小风同时收到艾薇儿的新歌海报推送。小风一看艾薇儿出新歌了，立马打开音乐播放器，听了起来。小西则看着海报，艾薇儿把头发染成了蓝色，身穿黑红相间的卫衣，身上挂着一把吉它，右手指向前方。“不愧是女神，还是这么酷这么朋克”，小西慢慢的欣赏着海报。

以上的两个场景可能我们中的大部分都经历过，一千个读者就一千个哈姆雷特，每个人看待世界的角度都是不同的。因此，我们想要提炼出 core domain,首先我们要先明确一个点，我们站在哪个角度看待问题的。

时间维度

即使有理论去说明我们可以穿越时间，但毕竟都没实现过。所以我们可以这么认为，时间是最稳定的东西。任何事务肯定会在时间的长河上留下足迹，并且一旦留下足迹，肯定是一成不变的。我们按时间的维度来描述事情，一般会说，某时某刻发生了什么事。这里的【事】我们可以理解为事件，某时某刻一个什么事件发生了。比如场景二中，小风收到艾薇儿的新歌海报推送，就是那个时刻，【艾薇儿发新歌】这个事件发生了。那么，我们站