认识达内从这里开始

领域驱动设计随着互联网的不断发展而被越来越多的程序员掌握，今天我们就通过案例分析来简单了解一下，领域驱动设计应用实践注意事项分享。

通用语言：在做领域划分之前一定要统一领域通用语言，如果一个名词在用语言描述的时候在不同语境有不同含义，那么就应该在不同语境中创建不同上下文。比如book，在写作阶段就是草稿，在出版阶段就是一个出版物，在购买阶段是一个书籍类商品，在发货阶段是一个物流订单。那么就应该按照书的角色进行归类，区分出上下文。正所谓，在商言商，在领域就应该说领域的通用语言。

领域职责：不同领域想要达成的目标是不一样的，每个领域都有自己终要完成的事情，即通过领域知识，完成领域活动，后完成领域职责。

领域角色：不同领域的角色也不尽相同，前端领域里可能需要ue角色、fe角色。后端领域里可能需要java研发、dba等角色。同时上边举的book的例子，book在不同领域的角色也是不一样的。再通俗一点，你在学校是学生角色，上班是员工角色。

领域知识：不同领域包括的知识是不一样的，比如后端和前端，后端可能需要了解服务器相关的知识、前端需要了解的是界面相关的知识。

领域活动：不同领域的职责也是不同的，在领域内进行的活动也不一样，比如前端需要构建前端页面活动。后端处理数据库交互活动。领域活动会利用到领域知识，如果进行领域活动的时候却不具备这个领域的知识，那么说明领域划分是不合理的。

领域关注点：不同领域关注点不同，拿person举例，person有身份证信息、年龄、身高、体重、工作、专业等信息，但是在不同领域对person的关注点是不一样的，银行办信用卡不需要身高体重信息、参加奥运会却关注身高体重，相亲时不会关注身份证信息，但却关注你的工作、年龄等。

在落地过程中我们遇到了一个建模问题：

我们的服务有两个角色使用：

运营人员：运营人员要配置模型的各种规则，但是频次相对较低。

用户：用户会使用运营人员配置的规则，使用频次较高。

在项目初期由于设计问题，终放弃了拆分这两个上下文，而是使用相同的上下文进行了建模。

这个问题的本质是我们没有想好领域划分，现在回头想想，我们处理的是一个核心域，但是这个核心域又可以分为两个子域：一个是配置平台子域，一个是用户使用子域。

两个子域的关注点是不同的，并且变化频次也不同，后续用户使用上下文会做横向扩展，我们目前的单体架构虽然能做扩展，但是不符合单一职责原则，因为用户使用平台集成了配置功能，而配置功能是不应该随着用户功能进行扩展的。在拆分过程中，会有很多代码是重叠的，我们的服务中就有很多Aggregate聚合，在两个上下文中有很多字段是一样的，但重复并不一定是错误，因为重复的代码关注点和变化频率是不一样的。这里我们介绍了利用角色进行关注点区分，进而划分子域和限界上下文的方法，实际上也可以根据其他条件对领域进行划分，划分只要保证概念相对独立，关注点相对独立，划分后没有丢失问题就可以。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。