阅读文章《DDD 领域驱动设计－如何 DDD？》的阅读笔记

文章链接：

https://www.cnblogs.com/xishuai/p/how-to-implement-ddd.html

文章作者： 田园里的蟋蟀

首先感谢作者写出这么好的文章。

以下是我的阅读笔记：

1、进行战略建模时不要考虑技术性的东西，不要考虑战术建模的概念，需要搞清楚业务，搞清楚业务的核心，把业务核心功能描述出来。
如文章中举例，微博的评论提到功能，描述其业务：评论时@一个人，然后通知被@的人
核心业务是两个：1、匹配到@的人，2、通知@的人

2、作者把Mention，即“提到”作为一个聚合根，并且定义了两个方法：抽离出@的对象，通知@的对象。
丰富了Mention这个领域模型。当提到规则改变时只需要修改Mention。
这个思考过程有几个点：理清核心业务是匹配人和通知人；把提到作为一个领域模型，一个聚合根；
给这个实体赋予两个方法，变为充血模型。
应用层的应用服务只是牵涉到流程，而不牵涉到业务，只是起到了聚合操作的作用：抽取用户、判断更新、持久化、通知

3、作者的另一个例子是 “权限申请和审核系统”
首先在了解业务的基础上进行战略建模以及描述出核心业务：
业务描述：用户申请权限，管理员后台审核权限。

核心业务是什么，以及判断的依据是什么呢。
核心业务的判断条件：一般核心业务包含在简单的描述里，比如“提到”系统里的“抽离”和“通知”
还有一种方式是判断其是否经常发生，对于业务流程一般不发生变化，变化的是核心业务，DDD应对的就是这种变化。
核心业务就是申请本身，这里我称之为申请单。
我的判断：
核心领域：申请单
申请单作为聚合根和实体，可以包含通知用户审核结果和开通权限两个领域
领域事件：开通权限和通知用户。

疑问：验证用户信息和验证是否有资格申请的验证放哪里。
通知用户是否需要作为一个实体。
解决疑问(注：我的方法是错误的)：验证用户信息、验证资格和通知都可以放在申请实体这个领域模型里，作为领域事件。

反思：作者把验证用户信息和资格放在了领域服务。我是放在领域事件里，我想错了。