最近发现文章老是被窃取,有些平台举报了还没有用。请识别我的id 方丈的寺院
。
DDD领域驱动设计,起源于2004年著名建模专家Eric Evans发表的他最具影响力的著名书籍:Domain-Driven Design –Tackling Complexity in the Heart of Software(中文译名:领域驱动设计,之后进行了很多迭代和演化,不过大多没有脱离这本书讨论的范围。因为Eric Evans在该书中只是提供了一套原始理论,并没有提供一套方法论,更别说可落地。所以十几年,对于DDD争论不休,毁誉参半,喜欢的人觉得他解决了软件设计的复杂性,不喜欢的人觉得他使得代码设计更加复杂了。
关于DDD的理论讨论,案例分析的博客也浩如烟海,但是关于他应该如何被引进团队,一步步实施下去,却很少见,导致很多人想从0开始的人,不知道如何开始。所以我在写DDD系列开始前,先写一下DDD是如何在我们团队落地,希望能够对你有所启发。
现代互联网产研团队的构成一般是市场/运营、产品、UI交互、前端、后端、测试。这些角色的分工是将一个产品开发上线的各个过程拆分出来,然后每个过程专人负责,可以有效提高生产效率,这一套流程是标准的流水线作业。这样做的好处毋庸置疑,坏处也很明显,每个人只盯着自己那一块,而忽略整体了。
再来看DDD,领域建模设计核心有两个
为了实现这两个核心,需要一个关键的角色,领域专家。他负责问题域,和问题解决域,他应该通晓研发的这个产品需要解决哪些问题,专业术语,关联关系。这个角色一般团队是没有配备的。最接近这个角色的就是产品了,但实际上产品并不是干这个活的。在我们团队落地过程中,有一段时间苦于没有领域专家,我想push产品成为领域专家,担当起这个角色。 最后不了了之,产品很配合,但是内驱力不强。为什么内驱力不强,因为给他带来的收益不够。
前面已经提到敏捷迭代后,每个角色都是流水线上的螺丝钉,大家都只盯着自己这一块。对自己有利的去参与,和自己无关的不管。
我们先看统一语言与面向领域的好处
这些好处粗看一下,其实对产品研发的各个角色都有意义。但细看一下呢,沟通成本大大减小,对于运营,产品,UI交互没啥问题。一个问题理解的不一致,组织个会议,大家好好聊聊就行了。用户体验一致对产研团队有啥好处呢,反正用户骂的不是我,是客户和运营。深入分析产品的内在逻辑有啥用呢?一款产品的成功有很多因素,主要靠上面,我只是一个小兵,我管不了那么多。有空我多研究研究我的专业领域,多去看几篇面试文章。产品黄了,我好跳槽。
因为本人是后端研发,所以这里不对其他角色过多展开。只想对研发说,你跳槽换个公司就好了吗?还是crud boy。还是重复着写着很多冗余的功能,冗余的代码。需求方让你写什么,你就写什么,最后在一天天的加班中丧失了对代码的兴趣,没有了梦想。 我们都知道改变别人很难,所以先从改变自己开始,先让自己变优秀了,才能影响他人
如果抛开其他角色,单从研发角度考虑DDD呢。开发进行领域建模,然后遵从康威定律,将软件架构设计映射到业务模型中。(虽然这个领域,开发可能识别的不对,暂且忽略这个问题)
康威(梅尔·康威)定律 任何组织在设计一套系统(广义概念上的系统)时,所交付的设计方案在结构上 都与该组织的沟通结构保持一致。
纯研发实施DDD,为什么也这么难呢?
DDD是一套思想,一套领域建模设计,一套在特定上下文环境中使用的。所以在1千个团队中实行DDD,可能有1千套不同的方案。一个实行DDD多年的人,换了一个公司,换了一个团队,把他原有的那套带过去,推行下去,一般都不适用。
所以DDD的学习和实践不像学习一个函数,API,框架那样有直接的反馈效果,他需要结合团队的实际情况去实行,才能达到效果。
程序员都是很实际的,没有好处的东西是不会去做的。你必须能够有效的帮助他提升,他才会去接受。 比如当初有团队成员提出来,
我们实行了这一套后,是不是不用加班了,或者加班时间可以减小。
有测试提出
实行这一套后,bug率能降低多少。
研发需要一个可以量化的效果,抱歉DDD做不到。没有哪个团队实行了DDD后,解决了软件开发的所有问题。关于这一点,可以读一下驱动方法不能改变任何事情
结合我们团队的实际情况,经过上面一系列的讨论,我们首先确定了我们期待的DDD落地的目标
之后我们就围绕着这个目标,开始实行DDD,欲知后事如何,请听下回分解。
关注【方丈的寺院】,第一时间收到文章的更新,与方丈一起开始技术修行之路