建设网站制,免费制作视频的软件有哪些,市场营销推广策略,临沂做wish网站作者#xff1a;闵大为 阿里业务平台解决方案团队 当我们在学习DDD的过程中#xff0c;感觉学而不得的时候#xff0c;可能会问#xff1a;我们还要学么#xff1f;这的确引人深思。本文基于工作经验#xff0c;尝试谈谈对DDD的一些理解。 一、序 《阿甘正传》中#xf…作者闵大为 阿里业务平台解决方案团队 当我们在学习DDD的过程中感觉学而不得的时候可能会问我们还要学么这的确引人深思。本文基于工作经验尝试谈谈对DDD的一些理解。 一、序 《阿甘正传》中阿甘开始了不停地跑步一段时间后后面就有了很多追随者一起跑他们为什么跑呢 阿甘我也不知道只是想跑而已。 追随者感觉这样做是有意义的而且阿甘也还在前面领跑。 类似地一开始我也不知道DDD是什么但当发现大家都在提DDD、都在学DDD的时候我也像跟跑者一样不由自主地加入了前行既然有大牛提出了DDD既然那么多人趋之若鹜那么肯定有可取的地方。 然而有一天阿甘停止了跑步他不想跑了追随者遇到了一个问题我们还要跑么当我们在学习DDD的过程中感觉学而不得的时候可能也会问我们还要学么这的确引人深思。 本文基于工作经验尝试谈谈对DDD的一些理解希望能够更好地探寻学习DDD的意义。 二、关注DDD的价值 无论做业务还是做平台、中台大家常常会被交错复杂的业务逻辑、晦涩耦合的业务代码搞得心力交瘁。我想大家对DDD的追求也是对轻松支撑业务发展的诉求在探寻有没有合适的理论可以改善现状。毕竟美好生活共同向往。 2.1 现状分层支撑机制 我们选择各种框架、进行各种组织设计核心是为了提高生产效率。但如果业务逻辑都是case by case地进行实现、缺少复用那么研发成本是非常高的、投入周期也会非常长。 为了增加复用、缩短业务的落地时间就需要很多通用的能力、产品。在我们的交付过程中主要有两个层次 基础能力相对原子的能力是基础域能力这个可以较好地支持业务定制。由于比较基础表达的产品能力范围也是很大的。但是一个完善的产品需要串联的基础能力是非常多的串联的成本也是非常高的。 平台产品基础能力的通用性意味着缺少对场景的理解缺少了进一步提升生产效率的“基因”。所以在交付的时候会基于一些高频场景进行抽象形成平台的产品能力争取做到“拆箱即用”。业务基于“平台产品”这层进行定制的时候理解成本会大大减少。 分层支撑框架 2.2 腐化业务逻辑渗透 这样的层次看上去很美好在起步阶段由于缺少历史包袱的确可以提升一定的生产效率这是能力本身的收益。但是越往后随着业务接入的增多业务之间开始互相影响研发的阻力也越来越大。 研发效能降低的重要原因在于更多的时候我们还是按照“业务能跑起来怎么快怎么来“的逻辑去做相关工作遇水搭桥遇山开洞然后直达目的地进行信息的传达、数据库字段的操作。 这样的过程违背了我们”希望通过业务场景丰富平台能力同时保证内核干净“的初衷。能力应该是基于相对多的用例、相对完善的思考进行抽象是横向统一看有更深刻的理解但是垂直的交付让我们更加纵向地处理问题往往只是“窥探”了链路在交付时长和业务节点的限制下很难想得更加全面、深刻难以做出更通用的设计。 2.3 抵御平台框架守卫 那么为什么关注DDD如果说DDD直击了软件复杂度的核心——“问题域”那可能还是比较抽象。具体来说因为这的确符合我们追求的价值观【提升长期的生产效率】 细分领域培养专业的人、事因为DDD的核心是要求让各个领域做好理解和封装把一个业务需求拆解、安放在各自合理的地方通过这样的分解与沉淀保证了领域的输入能够得到长期可持续的发展形成竞争力。 机制保障不依赖易变的事物DDD其实在总结很多通用的技巧和经验能够让这样的实施更具有确定性。无论是聚合根对领域实体的管控能力、限界上下文的交互策略、领域内核的抽象地位...等等一旦选择尊奉确定下来就能够落在代码结构、组织关系、团队文档中形成共识不会因为人员等因素的变化而剧烈波动。 对DDD的关注可以类比于我们对“工匠精神”的关注对DDD的重视也是我们对业务理解的重视。贴近业务更要理解业务不仅要理解业务更需要理解大多数的业务。这样的追求让我们往上看了一个层次回归了最本质的问题我们要解决什么问题如何能够解决得更好 三、学习DDD的困难 不知道大家是否有这样困惑DDD的学习过程好像是”大海捞针“的过程。即使能够捞到点东西使用起来还是会有种“东施效颦”的感觉并不是很自然。为什么学习DDD那么困难呢 3.1 感受不得其门 论语中的下面这个场景和我们的困惑是比较相似的 叔孙武叔语大夫于朝曰“子贡贤于仲尼。” 子服景伯以告子贡子贡曰“譬之宫墙赐之墙也及肩窥见室家之好夫子之墙数仞不得其门而入不见宗庙之美、百官之富。得其门者或寡矣夫子之云不亦宜乎” 正如要感受到孔子达到的境界自己的学问也需要有一定的积累。我们要感受到DDD的力量自己本身就要成长到一定程度如经历了一些成功或者失败的设计有自己的经验或者教训才能形成共鸣和认同。 工作中的确很少看到DDD的最佳实践。在复杂的业务面前谁也没有勇气说哪个软件结构是理想的设计 因为这不是一个确定性的问题分解你的设计会被放在显微镜下研究总能找到各种反例。 而且我们深知最佳的实践一定是做得足够的“软”对扩展留有设计能够随着业务发展而迭代不是一个静态的结果。 因此打开学习的大门不是几个案例就能一蹴而就的需要结合我们自己的工作慢慢累积、体会。 3.2 困难模式发散 我们有一种困惑到底怎么样算是DDD 实践的个例难以信服当我们看到“DDD实践”的时候可能会发问这也算DDD不就是一个正常的服务端框架与方案也无法涵盖其它的场景或者部门系统。 抽象的理论觉得空洞当我们看到“抽象的DDD定义与策略”的时候可能会发问这也算DDD不就是一些软件设计的共识然后强加了一些名词定义有些策略与我们手上的系统也并不匹配。 无论往抽象看还是往具体实现看都很难找到令人信服的理论与实践能够有确定性的落地能力。因为这不像23个设计模式那样可以通过N个模版就能涵盖大多数的模式。 为什么不能产生特定的模式呢可以结合下图进一步来看 抽象理论如同抽象的接口一样“DDD理解”最上面的学习主要是理论定义比如聚合根、值对象、资源库、核心域、支撑域等各种定义这些是易于理解掌握的。 通用实践如同相对具体的抽象类一样“DDD理解”中间层次是一些通用原则和技巧比如上下文的映射策略、架构的选择等。这些因素是确定的但需要自主进行取舍与选择并且需要与时俱进增量的部分需要自己学习补充。 具体实践如同具体的类实例一样“DDD理解”中下面层次是一系列的具体实践结合各自的业务场景进行了不同因素的设计、取舍与补充。因为涉及的选项较多造成最终的选择结果往往是发散的令人感觉“千人千面”。 两者不同的地方是 “代码抽象层次”中层次关系是比较明确的且有约束。 “领域驱动理解层次”中无法提供明确的约束都是多个策略的取舍、一些关键的建议。 因此由于问题的抽象层次较高各种策略的不确定性较高很难在DDD中产生像“23个设计模式”那样精炼的模式。一定要有的话也是一系列的模式比较发散。 DDD理解层次的类比 因此我们渐渐明白DDD面向的是软件的“软”涵盖方方面面。DDD的深入理解需要“千锤百炼”后才能明白那些深入简出的建议才能体会那句“师傅领进门修行靠个人”的箴言才能感受到“众里寻他千百度那人却在灯火阑珊处”的美妙瞬间。 四、基于设计原则看DDD 虽然DDD本身的实践可能千人千面但是一些核心主题的思考应该是聚焦的这些高频主题的理解能让我们更好地进行设计讨论的性价比也是较高的。接下来会基于“6大设计原则”solid 原则为引子去看看DDD中的一些关键理解。 4.1 单一职责原则领域划分 单一职责是说一个类应该只有一个发生变化的原因。职责的单一可以更好地内聚减少耦合方便演化。 DDD里面的领域划分可以类比思考。对领域的划分无论是按领域实体还是按照功能模块还是按照服务等划分其实都想尽量保证领域的正交能够独立演化和发展。 Single Responsibility Principle单一职责原则 领域怎么切分比较合适刚进入业务平台的时候了解到领域切分是按“一个或多个实体对象”的边界来切分。这的确比较合理因为领域的核心职责就是对领域实体进行管理。但这是果还是因在切分的时候是因为我们有了对领域的判断所以某些实体被分在一起比较合适还是因为某些实体有明显边界所以可以形成一个领域就比如下面的图 可以整体作为1个部分。 可以按竖着的正、负切分2个部分上面1个红下面2个黄、绿。 可以按横轴的正、负切分2个部分左边1个黄右边2个红、绿。 可以切分成3个部分红、黄、绿。 聚类的例子 这的确引入深思。切分比较容易的时候往往是因为已经有了行业的标准如电商系统有订单、支付、物流、库存等领域是比较合理的。那行业的标准来自哪里是来自于演化 开始的时候可能只是一个大交易比如支付开始的时候只是买卖双方自己协议也不需要建模。 后面支付发展了也就独立出来一个域。原来不需要专人维护后面会渐渐拉出一个团队来承接相关研发。 所以领域的演化和划分很类似“启发式算法”一个基于直观或经验构造的算法在可接受的花费下给出待解决组合优化问题每一个实例的一个可行解 初始化按照的经验初步的划分也可以是行业标准没有行业标准的时候就只能靠经验了。 花费评价生产、交付过程的人力成本度量关注理解成本、开发效率、系统稳定性、运维成本等因素。 更优解在业务发展过程中计算花费评价分析影响评价的“好因素”、“坏因素”进行进一步调整。 往往到最后我们会发现 调整的内容其实是匹配生产关系。 调整的原则追求职责的内聚精细化分工。 不断调整的原因业务在发展内聚的标准也需要与时俱进。 此外从关联的角度看往往我们看组织架构就能看到领域的边界核心原因还是组织架构也是要适应生产关系follow更优解的结构是相辅相成的也就能互相窥探。 4.2 开闭原则实体行为 开闭原则是说软件中的对象类、模块、函数等应该对于扩展是开放的但是对于修改是封闭的。也就是说对扩展区块是要有设计的扩展的部分不应该影响稳定逻辑。 在DDD中实体的行为在保证对外封闭的情况下也是需要考虑扩展能力的。 Open Closed Principle开闭原则 在刚开始学习DDD的时候我们可能会强行把一些逻辑放到实体中进行控制和收敛。但后面随着业务的变化会发现在实体中承担行为逻辑很难受 影响较大很难有勇气去频繁地修改一个核心类。 过于集中随着方法和逻辑的增多实体越来越臃肿。 场景较多很多逻辑并不是正交的不是if这样else那样的充满着交集与叠加。 抛弃POJO的get、set走向实体的丰富行为让我们编写代码更加困难了么其实我们的烦恼来自于太关注实体行为的收口忽略了扩展的设计 原来get set写法很舒服的本质在于很多的扩展被放在了业务脚本中业务脚本虽然千疮百孔但是是在应用层远离核心逻辑。底层模型、通用组件等基础逻辑还是比较干净的。 应用DDD的时候把一些行为下沉到领域层之后也是要考虑扩展的。如果只关注收口不关注扩展那的确是“画地为牢”、“捡了籽麻丢了西瓜”。 但是要突破这一个困境能够在实体行为中设计扩展其实要有这样的认同要往上看一个层次就是实体行为的表达不一定只有一个类完成可以通过策略模式等方式的路由由一个模块中的一些类进行完成只要对外有封装和管控就可以。 突破一个类的限制走向更多的类的协作设计也是我们进阶的方向。 4.3 里氏替换原则资源库 里氏代换原则是说任何基类可以出现的地方子类一定可以出现。讲究的是合理的抽象和复用。引人深思的一个例子是正方形是特殊的长方形正方形如果作为长方形的子类那么当设置长度的时候就会出现冲突长方形的长和宽可以独立设置正方形的长和宽是有约束的使用继承的关系就比较别扭。 在DDD中关于可替代性想聊一聊资源库。 Liskov Substitution Principle里氏替换原则 资源库的替代性需求 在原来的分层的架构中数据库等存储能力作为一种底层基础设施是被视为稳定的下层服务的。但在实际的交付过程中往往要遇到不同场景 本地部署线下零售交易为了服务稳定性期望可以具备本地保存数据的能力。 云上产品售卖给外部企业的交易产品成本的要求也不尽相同期望在云上采购不同的存储服务。 这些场景让大家逐渐深信当面向更广阔的市场基础设施也是充满着不确定性需要具备可替换的能力。 存储实现间的复用策略 在具体实现的过程中并不是每个领域都会独立部署有些领域因为组织、性能的因素会一起部署。往往这些领域的代码也是在一个项目模块中的。出于横向效率的考虑会设计统一的存储框架。 不同设施的存储能力不同但整个存储流程又是类似的协议转换存储语句生成、执行与事务返回结果这样在不同存储能力的过程复用方式上需要进行取舍数据库、Tair等是分开抽象还是统一抽象 如果“大一统”为主那么针对关系型存储、KV存储等不同存储进行抽象的时候就会和“长方形与正方形的问题”一样犹豫 收益如果你长期维护了解里面的特殊性的确是可以省略一些主体代码提高开发效率。 代价但大多数人要做扩展的时候会感到很多不解有很多本不需要的适配充满迷惑。 如果以组合为主那么可以通过多套模版更好地进行自主选择。这样分而治之减少了大家的理解成本也能独立演化更能适合存储的能力特性。但是需要沉淀多套理解往往也缺少人力支持。 我想“基于不同的存储能力设计不同的模版框架” 应该是首选。大一统的抽象开始时人力成本可能低一点但因为抽象层次较高在理解与维护上将是一个“人力成本黑洞”随着时间的推移会降低整体收益长期看是得不偿失的。反之不同的模版复用最终可以获得更好的整体收益。 4.4 迪米特法则领域协作 迪米特法则又称最小知识原则是说一个软件实体应当尽可能少的与其他实体发生相互作用。应该和一些“关键类”进行沟通。 DDD里面领域间的协作也需要相关的规划和设计。如果对领域之间的相互调用不做管理那么链路关系会膨胀到难以理解的地步。 Law of Demeter迪米特法则 设计模式中无论是中介者模式还是外观模式都希望通过集中管理让多对多的复杂关系简化为多对一、一对多这样易于理解的结构。类似的在领域协作与对外交付的过程中往往可以增加一个协调层去串联各个域的交互。这样即可以降低各域的协作成本也可以降低外部的理解成本有更好的研发体验。 协调层该如何产生好比上课虽然老师可以教但是老师不在时可以指定学生代理上课。学生虽然可以干但教学技巧并不熟练自己本身还有学习的职责角色也很尴尬。下面将讨论一下协调层和域的角色关系。 域能否成为协调层 比较值得讨论的是交易里面“交易域”、“订单域”这样的概念 “交易域”看上去是负责整个交易过程可以协调各个域逻辑上比较合适成为协调者但是主要还是在管理订单其它赋予的协调能力这部分并没有领域实体。 “订单域”看上去只是负责订单本身的服务不太关心其他域但是因为订单合约上有着所有合约信息无论是直接还是间接持有这意味着“订单域”本身就有协调的潜力只是职责看上去不够单一而已。 没有实体为什么会有“交易域”一说本人是这么理解的在交易流程等可以强管控的情况下把交易的API服务当做域服务如下单“交易域”在逻辑上是有边界、可以成立的。但本质还是在管理订单靠订单域成为了域同时想沉淀协调能力。 协调层能否成为域 那么如果订单的模型的管理不给交易管理呢就是本人一直想的问题如果没有自己的数据库实体只有内存模型纯粹靠对下游业务活动理解、数据流转的理解能否成为一个域 答案大概率可能是不行的 逻辑上个人是认可纯靠理解作为一个域毕竟知识本身也是一种资产。 但实际上没有载体就做不了特别多事情包括状态记录数据服务等只能辅助没有核心竞争力难以生存下来。 协调者的角色想要成为一个比较公认的“域”必定要自己持有数据模型或者借助基础域的一些数据模型并享有管理的权限。 协调层的名称 无论是域想承担协调者的角色还是协调者想发展成一个域其实都不太符合职责单一的逻辑但是这样“兼职”的现象却时常发生核心还是开发人员角色的重叠。 既然协调层不太适合从域中选出也不太适合成为一个域那么介于业务活动、各个域能力之间的协调部分应该称之为什么目前看“商业能力”、“解决方案”这样的词汇都是比较合适的。 4.5 接口隔离原则业务活动 接口隔离原则是说客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。 DDD里面除了领域建设的学习也需要关注应用层如何更好地承接业务请求并研究业务逻辑分割的依据。 Interface Segregation Principle接口隔离原则 没有规矩难成方圆 之前在业务部门做业务的时候并没有业务活动、流程等相关概念往往是基于业务需求写业务脚本经验的多少会影响代码的优雅。但除了经验大家并没有比较好的结构框架、原则去承接应用层的各种业务逻辑因此也充满疑惑 对外服务接口应该如何切分 类似服务之间是否可以共用流程 业务执行过程如何进一步结构化切分 ...... 没有规范的结果是往往各有各的看法谁都想立一套结构谁也不服谁起的一套各有各的代码区域。 平台的稳定框架 现在工作中因为在平台平台思考和治理的时间也比较久了也有比较稳定的共识。整体的设计在业务入口和业务入口之间、业务入口和稳定逻辑之间预留了空间和扩展能力去承接场景化的逻辑结构也比较确定 入口按业务活动切分服务入口按照业务活动扩展核心理解并关注用例什么角色要干什么事情。 流程独立承接与编排业务活动在到达复用层如领域服务、外部服务、业务扩展前保持独立各自编排。 借助流程文件编排执行过程将执行过程切分为执行节点节点的切分可以以“功能点”、”涉及的域“、“涉及的实体“等为依据。节点间的共同能力下沉到基础能力中。 ...... 反复review形成共识 分而治之缩小大家的关注点更好地切分协作这样的确很容易理解并接受。但是要保证合理的切分还是要有统一的共识和原则。 往往一致的形成不是先一致共识再切分而是初步沟通后就尝试切分再review达成一致在曲折中前进。如果大家的看法、冲突较大那么这个共识达成的过程就相对较慢。好在这种切分也不是时常发生也就大需求、大重构的时候。此时预留的研讨时间、开发资源也是充足的。 4.6 依赖倒置原则六边形架构 依赖倒置原则是说程序要依赖于抽象接口不要依赖于具体实现。 DDD里面提到的六边形架构也是进一步提升了抽象内核的地位把领域建设作为架构的核心目标。 Dependence Inversion Principle依赖倒置原则 以领域为中心其实是一个比较重要的转变 原来以分层架构为主讲究按层次去看尽量将能力下沉进行更多工具复用积累的是通用组件。 现在以领域为中心讲究按抽象层次去看尽量将理解融入到领域核心进行更多“理解”复用积累的是业务知识。 这样的转变让我们有意识地将“领域理解”作为核心形成行业竞争力把“知识”作为资产进行售卖。 为了保证领域内核的抽象需要定义好领域内核的边界有两类接口 对上游提供的能力通过接口声明说明能承担的职责在领域内部进行实现支撑。 对下游的能力依赖外部服务、业务扩展定制、存储服务都可以作为下游服务看待通过接口声明服务依赖。 可以看到领域内核与外部之间通过接口进行解耦。对于更基础的服务会被视为和业务入口一样的外部端口属于应用层。比如存储服务 原来更多的是基础能力数据框架 DO不需要理解转换转换在上游完成DO也会作为核心模型被上游使用在采用遵循模型策略的时候上游完全使用DO作为核心对象进行流转。 现在可以理解为“业务组件“需要实现领域的存储接口承担协议转换将领域对象转换为数据存储对象DODO也不会被领域直接理解需要转换为领域对象再往外透被领域内核定义了表现。 这样的架构奠定了领域理解的抽象核心地位让研发同学更加注重对业务问题的思考建设更多“有血有肉”、“贴近业务核心问题”的软件不仅仅是“基础骨架”让我们更加走近客户的价值是应对软件复杂性过程中大家比较认可的方向。 五、总结 对DDD的追求来自我们渴望优雅地解决各种业务问题希望有一套框架可以引导我们去分解问题得到稳定、高效的生产效率。 但是这好比对“永动机”的追求是一个难以有肯定答案的过程。能够解决软件复杂性的方案必定是结合相关场景并且不断演化的单纯追求DDD是得不到“银弹”的。 不过正如对“永动机”的研究能让我们关注能量的转换过程可以引导我们制造出更加高效的能源机器。对DDD的研究与追捧能够让我们更加关注对业务的深刻理解可以引领我们写出更加易于扩展的代码实现。 我想正是“业务的不断发展”、“软件的复杂性”的存在才让编程充满了挑战才让大家对框架的研究充满热情这何尝不是一个美妙的事情。
