文章简介
在 B 端产品研发及我的项目施行中,DDD 带给咱们哪些思考?咱们是如何利用的?本文不是科普贴,旨在分享咱们的经验和思考。
背景
Domain Driven Design(简称 DDD),又称为畛域驱动设计,起源于卓越软件建模专家 Eric Evans 在 2003 年发表的书籍《DOMAIN-DRINEN DESIGN —TACKLING COMPLEXITY IN THE HEART OF SOFTWARE》(中文译名《畛域驱动设计—软件外围复杂性应答之道》)。随着 2014 年 Martin Flower 和 James Lewis 的《Microservice》出版,微服务概念为业界所承受,DDD 也被从新提起。人们发现,DDD 里的畛域、限界上下文、畛域模型等理念,和微服务的高内聚、低耦合理念有着人造符合,越来越多的人把 DDD 作为领导微服务划分的方法论之一,也有越来越多的人认为,把握 DDD 才是一名优良的架构师。
DDD 工作流程 – 图片来自于网络
限界上下文 – 图片来自于网络
为什么咱们要开始 DDD?
笔者所在团队于 2015 年左右开始进行公司自主产品的研发,过后,DDD 次要利用在咱们的微服务划分、代码分层中,对咱们过后从技术角度登程、搭建对立的微服务技术框架,有着重要的指导意义。而真正开始思考将 DDD 利用在具体的业务畛域与业务场景中,是在 2018 年末。那时,咱们面临着自主产品施行的我的项目越来越多、须要帮忙客户从 0 到 1 构建业务利用的状况,如何在企业甚至行业的简单业务场景中找到适合的架构计划,是过后咱们冀望借助 DDD 去更体系化答复的问题。
咱们是如何利用 DDD 的?
在 DDD 的实际中,大多数人应该都会面临一个问题:名词太多!“畛域”、“子域”、“限界上下文”、“聚合”、“实体”、“值对象”等等名词,令人目迷五色。并且,DDD 的实践尽管通知了咱们名词的定义和解决准则,然而具体场景之下,到底如何基于准则去剖析,如同并没有标准答案。
这也是咱们在利用 DDD 时的最大窘境,咱们也在重复思考:如何在团队内对立语言、如何把 DDD 准则融入到具体可执行的工作事项中?
接下来,咱们将从人和事两个方面来分享咱们的经验与思考。
人:
DDD 里强调,领域专家和开发团队独特工作。
领域专家 的退出,其本质在于让所有的设计回归业务自身,从业务价值登程,聚焦业务外围域,防止适度设计。
心愿领域专家和开发团队独特工作,往往是实际中的第一个难题,如何找到合格的领域专家?如何保障领域专家的工夫投入?如何最大化施展领域专家的“价值”?
- 对于合格的领域专家:领域专家不是指某一个特定的人,能够是很多人,可互相补充,但同时也不倡议过多。在寻找领域专家时,企业能够从本身的业务畛域登程,在每个业务畛域寻找到有丰盛教训的人员。这里的“经验丰富”并不仅仅是一线实战经验丰盛,更是对业务要有深度的了解和认知。
- 对于领域专家工夫投入的保障:在实践中会发现,有各种各样的“主观”起因,导致领域专家无奈无效投入。尽管有很多主观的状况,然而不论有如许艰难,保障领域专家的工夫投入都是必须要做的。如果领域专家都不参加,咱们怎么有信念讲咱们交付的是业务价值而不是一堆代码呢?
- 如何最大化施展领域专家的“价值”:把形象的问题具象化,通过凝听和疏导,更多地从企业的领域专家处取得信息,放弃“我是专家”的执念。
开发团队:在少数的信息化我的项目中,常见的分工是需要分析师进行需要收集与设计,技术人员负责开发和实现,需要分析师进行测试验收。在 DDD 实际时,倡议开发团队的业务架构师、技术架构师、测试架构师从一开始便独特工作,这样才可能施展每个角色在各自业余畛域的短处、逐渐对立语言、疾速达成共识。
事:
DDD 辨别了策略设计与战术设计两个档次,提出了聚焦外围域、创造性合作、对立语言的三个准则。很多人在刚开始利用 DDD 的时候,会感觉本人都“不会谈话”、“不会做事儿”了。这其实是因为过于关注名词自身,陷于对名词的了解和解释上,因而,在“事”上,咱们认为,须要抓住两个要点。
- 找到更难受的形式
DDD 通过策略设计解决业务边界划分的问题,通过战术设计实现畛域模型的形象,解决的是从业务到技术的过渡。
在谈 DDD 的时候,肯定绕不开事件风暴。“事件风暴(Event Storming)是一种疾速的设计技术,让领域专家和开发人员都能够参加到这个快节奏的学习过程中。它聚焦于业务和业务流程,而非名词概念和数据。”(摘自 Vaughn Vernon《畛域驱动设计精粹》)。事件风暴为 DDD 策略与战术落地,提供了一种十分有逻辑、有体系的办法,那么在这个办法之外,还有没有其余的办法呢?答案是,有的。尤其在 B 端企业的信息化建设中,瀑布施行方法论、麻利开发等等十分多优良的办法与工具,都能够为咱们所用。
在 DDD 的落地过程中,咱们外围的是要抓住最终要取得的后果,在过程中所采取的形式,能够依据理论状况进行调整,要害是要找到一个让大多数团队成员都难受的形式。以笔者的经验为例,有一家客户习惯了以流程图的形式进行业务梳理,在这种状况下,应用事件风暴的形式会对客户的习惯造成冲击,甚至让客户不晓得如何输入。此时,咱们就应该及时调整,思考流程图与事件风暴如何交融,既能以客户习惯的形式推动,同时也能拿到咱们想要的后果。
- 将准则与概念造成模板与具体工作工作
一千个人有一千个哈姆雷特,每个人对 DDD 准则、概念都有本人的解读。为了更疾速地在团队内达成 DDD 落地办法的“对立语言”,倡议以具体的工作工作、产出物模板来承载,让团队更聚焦在指标与工作的达成上。
通过在自主产品的研发和施行我的项目中利用 DDD 并继续迭代其利用办法,咱们不仅无效地实现了中台我的项目的施行、为客户构建了正当地利用架构,也逐步完善了我的项目施行方法论体系,为更宽泛地我的项目交付和产品研发提供了助力。DDD 帮忙解决了产品架构设计中的一部分问题,在架构设计之后,如何保障设计的落地、高效地交付,是每个团队会面临的下一个问题。在这里,笔者举荐应用猪齿鱼这款数智化效力平台,它能够无效治理架构设计所造成的微服务或模块,拉通设计与开发,通过提供合作、测试、DevOps、容器工具,进步团队效力。
猪齿鱼数智化效力平台
当初咱们是如何了解 DDD 的?
DDD 首先是一种思维,“聚焦外围域、创造性合作、对立语言”,是对于价值发现、价值认定、探讨、凝听、共识、迭代。这种思维不仅实用于软件设计,也实用于日常工作、集体生存、家庭教育等等方面。咱们不可能在每个方面都做到完满,须要辨认要害要务、聚焦投入;咱们也不可能单独存在,须要与人连贯、深度凝听、踊跃反馈;咱们欣慰于共识默契,也有勇气承受差别,因为正是这些差别让咱们一直碰撞、更好地学习与成长。
其次,DDD 是一种办法,它辨别了策略设计与战术设计的,引入了限界上下文与对立语言,提供了实体、值对象、聚合、工厂、资源库等。同时,业界也有很多 DDD 的相干著述,能够帮忙咱们更无效地去了解这些概念与具体利用办法。当然,你自身所在的畛域与你的过往教训,也是利用这些办法时十分值得参考的。
软件的架构,究其基本是物理世界在数字世界的映射。在 DDD 的利用中,咱们不仅吸取 DDD 的思维与办法,也学习麻利、DevOps、测试、微服务等畛域常识,同时联合咱们既往的教训,逐渐总结和迭代了适宜咱们的一套架构设计体系与办法。正如 Eric Evans 所说的,“DDD 还未完结”,咱们也在继续实际与继续调整。
本文是基于笔者以后的认知与了解所造成的,欢送留言探讨。
本文由猪齿鱼技术团队原创,转载请注明出处:猪齿鱼官网
对于猪齿鱼
猪齿鱼 Choerodon 数智化效力平台,提供体系化方法论和合作、测试、DevOps 及容器工具,帮忙企业拉通需要、设计、开发、部署、测试和经营流程,一站式进步管理效率和品质。从团队协同到 DevOps 工具链、从平台工具到体系化方法论,猪齿鱼全面满足协同治理与工程效率需要,贯通端到端全流程,助力团队效力更快更强更稳固,帮忙企业推动数智化转型降级。戳此处试用猪齿鱼