DDD即领域驱动设计，是一种强调分析、建模和重新设计的建模方法论，而不是数据库表驱动。DDD解决核心的复杂业务设计，特别强调“核心”和“复杂性”。DDD只适用于业务系统。DDD简化了业务系统的实现，使业务逻辑高度内聚，聚合通过聚合根ID引用与领域事件松耦合。高内聚低耦合，可以随着业务需求的不断迭代，保持项目代码的整洁。通过四层架构设计/六边形架构设计，实现与基础设施和框架的解耦。DDD也解决了拆分微服务的问题。DDD解决业务问题。它使用事件风暴来识别域事件、识别有界上下文、识别问题子域、聚合，然后对聚合进行建模。不是为了解决数据查询和数据分析的问题。前面我们学习了如何通过CQRS来解决读写分离的问题。然而……在实际的DDD过程中，我们总会遇到一些不适合领域建模，无法简单通过CQRS解决的问题，比如为前端提供地址、性别等。选项界面如何实现，用户标签功能如何设计，评价功能如何设计……对于这些看似简单的问题，我们需要考虑的是如何避免过度设计，保持结构简单和扩展。为前端提供选项的场景有很多。一些选项是枚举类型，例如性别和订单类型；有些选项需要支持增删改查，比如商品分类，虽然实体需要通过ID来引用，但不适合作为实体存在。无论是枚举类型的选项，还是通过ID引用但不适合作为实体存在的选项，都应该作为值对象来使用。可以在应用层直接读写存储/缓存中间件，如mysql、es、redis。下面会出现的领域（业务）名词：达人：网红、名人、有粉丝团的个人、有一定影响力的个人；OTO探店：线上注册、线下探店、线上推广（主要服务美食点，为商家推广线下门店）；在我们的项目中，需要实现人才的标签化。当我们接到这个需求的时候，我们首先要做的就是分析这个标签能产生什么值，然后通过事件Storm看能不能分析出领域事件。结合项目的业务分析，我们项目中人才标签的价值其实是用来做利益匹配和推送的。在OTO探店业务场景中，兴趣匹配可以理解为根据人才的喜好，将相关门店的订单推送给人才。.经过分析，我们知道标签函数要做的是数据分析和算法推荐。另外，标签没有任何领域事件（行为、业务动作），标签没有领域上下文，不宜过度设计。另外，如果人才被贴标签/人才被打标签，那么标签就是人才的取值对象，人才的性别、年龄、住址等属性就是人才的取值对象。专家可以添加标签或删除标签。所以最终，我们实现的标签功能只是在人才的聚合根上添加了一个标签值对象。一种将修改标签添加到主聚合根的方法。另外，我们需要为前端提供标签选项，以支持管理员添加或删除标签。和实现常用选项一样，我们在人才聚合下单独提供一个应用层的LableService，直接操作数据库进行标签的增删改查。标签表的存在只是提供标签选项，人才只能从系统提供的标签中选择自己来标签，标签相当于只是一个选项。因此，专家的标签值对象不存储标签的ID，而是直接存储标签的名称。当标签选项被删除时，我们不应该为所有输入标签的用户默认删除他的标签。这其实是不允许的，就像我们不能随意改变用户的性别或者地址一样。只有当专家更新标签没有提供删除的选项时，让专家选择一个新的标签进行更新，更新后，所有旧标签将被替换，达到删除的目的。除了选项和标签，我们还有评估功能。根据事件风暴，我们分析了以下事件：专家完成任务后，商家可以对专家进行评价（每个任务只允许评价一次）b．商家评价达人后更新达人评分（如内容质量分）》商家对达人的评价涉及三个维度：任务、人才、商家。达人可以查看商家对自己的评价，商家也可以查看对哪些人才写了评论，也可以查看与任务相关的评价。显然，将评价功能放在任务上下文、人才上下文或业务上下文中是不合理的。因此，我们将用于评估的评估上下文，识别评估问题子域。作为评估上下文的聚合，业务评估专家可以在后期支持专家评估存储，专家评估存储是评估上下文的聚合，并且有多个评估聚合在实战DDD的过程中，我们在实现前端选项的过程中也做了详细的分析和重新设计s、标签函数和评估函数，目的是避免过度设计。继续摸索……
