最近发现文章老是被窃取,有些平台举报了还没有用。请识别我的id方丈的寺院
。
摘要
DDD领域驱动设计,起源于2004年著名建模专家Eric Evans发表的他最具影响力的著名书籍:Domain-Driven Design –Tackling Complexity in the Heart of Software(中文译名:领域驱动设计,之后进行了很多迭代和演化,不过大多没有脱离这本书讨论的范围。因为Eric Evans在该书中只是提供了一套原始理论,并没有提供一套方法论,更别说可落地。所以十几年,对于DDD争论不休,毁誉参半,喜欢的人觉得他解决了软件设计的复杂性,不喜欢的人觉得他使得代码设计更加复杂了。
关于DDD的理论讨论,案例分析的博客也浩如烟海,但是关于他应该如何被引进团队,一步步实施下去,却很少见,导致很多人想从0开始的人,不知道如何开始。所以我在写DDD系列开始前,先写一下DDD是如何在我们团队落地,希望能够对你有所启发。
DDD落地为什么这么难
敏捷迭代,放弃建模
现代互联网产研团队的构成一般是市场/运营、产品、UI交互、前端、后端、测试。这些角色的分工是将一个产品开发上线的各个过程拆分出来,然后每个过程专人负责,可以有效提高生产效率,这一套流程是标准的流水线作业。这样做的好处毋庸置疑,坏处也很明显,每个人只盯着自己那一块,而忽略整体了。
再来看DDD,领域建模设计核心有两个
- 统一语言(软件的开发人员/使用人员都使用同一套语言,即