一文探究学习DDD的意义
发布时间：2023-02-14 14:28:29 所属栏目：服务器 来源：互联网
导读：《阿甘正传》中，阿甘开始了不停地跑步，一段时间后，后面就有了很多追随者一起跑，他们为什么跑哪？ 阿甘：我也不知道，只是想跑而已。 追随者：感觉这样做是有意义的，而且阿甘也还在前面领跑。 类似地，一开始我也不知道DDD是什么，但当发现大家都在提DDD
|
这些场景，让大家逐渐深信：当面向更广阔的市场，基础设施也是充满着不确定性，需要具备可替换的能力。 【存储实现间的复用策略】 在具体实现的过程中，并不是每个领域都会独立部署，有些领域因为组织、性能的因素会一起部署。往往这些领域的代码也是在一个项目模块中的。出于横向效率的考虑，会设计统一的存储框架。 不同设施的存储能力不同，但整个存储流程又是类似的（协议转换，存储语句生成、执行与事务，返回结果），这样在不同存储能力的过程复用方式上需要进行取舍（数据库、Tair等是分开抽象还是统一抽象）： 如果“大一统”为主，那么针对关系型存储、KV存储等不同存储进行抽象的时候，就会和“长方形与正方形的问题”一样犹豫： 收益：如果你长期维护，了解里面的特殊性，的确是可以省略一些主体代码，提高开发效率。 代价：但大多数人要做扩展的时候，会感到很多不解，有很多本不需要的适配，充满迷惑。 DDD里面，领域间的协作，也需要相关的规划和设计。如果对领域之间的相互调用不做管理，那么链路关系会膨胀到难以理解的地步。 设计模式中，无论是中介者模式，还是外观模式，都希望通过集中管理，让多对多的复杂关系，简化为多对一、一对多这样易于理解的结构。类似的，在领域协作与对外交付的过程中，往往可以增加一个协调层，去串联各个域的交互。这样即可以降低各域的协作成本，也可以降低外部的理解成本，有更好的研发体验。 协调层该如何产生？好比上课：虽然老师可以教，但是老师不在时，可以指定学生代理上课。学生虽然可以干，但教学技巧并不熟练，自己本身还有学习的职责，角色也很尴尬。下面将讨论一下协调层和域的角色关系。 没有实体，为什么会有“交易域”一说，本人是这么理解的：在交易流程等可以强管控的情况下，把交易的API服务当做域服务（如：下单），“交易域”在逻辑上是有边界、可以成立的。但本质还是在管理订单，靠订单域成为了域，同时想沉淀协调能力。 【协调层能否成为域】 那么，如果订单的模型的管理不给交易管理呢，就是本人一直想的问题：如果没有自己的数据库实体，只有内存模型，纯粹靠对下游业务活动理解、数据流转的理解，能否成为一个域？ 答案大概率可能是不行的： 逻辑上个人是认可纯靠理解作为一个域，毕竟知识本身也是一种资产。 但实际上，没有载体，就做不了特别多事情，包括状态记录，数据服务等，只能辅助，没有核心竞争力，难以生存下来。 协调者的角色，想要成为一个比较公认的“域”，必定要自己持有数据模型，或者，借助基础域的一些数据模型，并享有管理的权限。 【协调层的名称】 无论是域想承担协调者的角色，还是协调者想发展成一个域，其实都不太符合职责单一的逻辑，但是这样“兼职”的现象却时常发生，核心还是开发人员角色的重叠。 既然协调层不太适合从域中选出，也不太适合成为一个域，那么介于业务活动、各个域能力之间的协调部分，应该称之为什么呢？目前看“商业能力”、“解决方案”这样的词汇都是比较合适的。 接口隔离原则：业务活动 接口隔离原则是说：客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。 DDD里面除了领域建设的学习，也需要关注应用层如何更好地承接业务请求，并研究业务逻辑分割的依据。 Interface Segregation Principle：接口隔离原则 【没有规矩，难成方圆】 之前在业务部门做业务的时候，并没有业务活动、流程等相关概念，往往是基于业务需求写业务脚本，经验的多少会影响代码的优雅。但除了经验，大家并没有比较好的结构框架、原则，去承接应用层的各种业务逻辑，因此也充满疑惑： 对外服务接口应该如何切分？ 类似服务之间是否可以共用流程？ 业务执行过程如何进一步结构化切分？ ...... 没有规范的结果是，往往各有各的看法，谁都想立一套结构，谁也不服谁起的一套，各有各的代码区域。 【反复review形成共识】 分而治之，缩小大家的关注点，更好地切分协作，这样的确很容易理解并接受。但是要保证合理的切分，还是要有统一的共识和原则。 往往一致的形成，不是先一致共识，再切分，而是初步沟通后就尝试切分，再review达成一致，在曲折中前进。如果大家的看法、冲突较大，那么这个共识达成的过程就相对较慢。好在，这种切分也不是时常发生，也就大需求、大重构的时候。此时，预留的研讨时间、开发资源也是充足的。 依赖倒置原则：六边形架构 依赖倒置原则是说：程序要依赖于抽象接口，不要依赖于具体实现。 DDD里面提到的六边形架构，也是进一步提升了抽象内核的地位，把领域建设作为架构的核心目标。 对上游提供的能力：通过接口声明，说明能承担的职责，在领域内部进行实现支撑。 对下游的能力依赖：外部服务、业务扩展定制、存储服务都可以作为下游服务看待，通过接口声明服务依赖。 可以看到，领域内核与外部之间通过接口进行解耦。对于更基础的服务，会被视为和业务入口一样的外部端口，属于应用层。比如，存储服务： 原来更多的是基础能力：数据框架 + DO，不需要理解转换，转换在上游完成，DO 也会作为核心模型被上游使用，在采用遵循模型策略的时候，上游完全使用 DO 作为核心对象进行流转。 现在可以理解为“业务组件“：需要实现领域的存储接口，承担协议转换，将领域对象转换为数据存储对象DO，DO也不会被领域直接理解，需要转换为领域对象再往外透，被领域内核定义了表现。 这样的架构，奠定了领域理解的抽象核心地位，让研发同学更加注重对业务问题的思考，建设更多“有血有肉”、“贴近业务核心问题”的软件，不仅仅是“基础骨架”，让我们更加走近客户的价值，是应对软件复杂性过程中，大家比较认可的方向。 （编辑：甘南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
