我在大厂实践领域驱动，架构师迷信DDD的代价，OOD可能更好！

纯真干饭人:
我自己的开发实践中DDD最有参考价值的就是充血模型（传统的MVC模型在面对复杂业务时通常会变成冗长的事物性脚本代码，增加业务理解成本），充血模型可以避免很多业务逻辑过多的分散在各个service中把面向对象搞成复杂的事物脚本，导致需要经常性的跳转查看业务逻辑。实际开发中我们通常会把service层作为代码粘合层来粘合封装在充血类中的具体的原子业务逻辑。这个是我的DDD实践，书中其他的部分实际操作难度很大，很难平衡开发效率，总不能因为搞DDD把项目进度给拖垮了不是[doge]

【回复】充血模型确实合理且可读性更强
【回复】[妙啊]最后一句话，那是PM考虑的事
【回复】确实，充血可以一定程度解决service臃肿问题，除此之外还有就是事件驱动的思想可以解决各个service耦合的问题
寒宸枫:
去年才被DDD折磨过的我。人员真的要有经验才能上手或者是充分时间去带着理解，处理问题。如果时间不够团队人员经验不足，根本做不了·······而且关于类的转换也真的头皮发麻，六层写出来有一堆大差不大的类，越写越暴躁。不过学了DDD以后对我而言更能理解业务和对象之间的关系了。在做业务划分系统设计的时候还多了种思路，这个倒是感觉挺好的。

【回复】回复 @寒宸枫 : 主要成本非常高，还是你说的人员技术负债问题，因为没做过，很多个分层情况。按照阿里的那个 cola 吧，n 多层，哪像固定思维的三层架构直接来。不过真正做的时候也像你说了，大部分思路和三层架构有共通性，可能充血-贫血，领域服务有点不同，然后多加一些层级，职责更加单一化了。
【回复】回复 @寒宸枫 : 确实， 对于那种几个人，十多个人就开发的系统哈，业务不怎么复杂，然后呢可能简简单单单层架构或者就算是微服务项目，大多数都是简单的 crud。这个时候反而用 ddd 就很坑，会发现按照那个书上/业界一些模板架构越来越复杂，还不如mvc咔咔咔一顿写， 方面快捷。 另外我个人感觉这个至少 p7+、p8 以上的得带着搞才能，而且这个业务领域得吃透，不然开发的时候很容易出现那种某某实体要增加某个通用语言啥的，感觉某个子域哈，某个小团队做了有个一两年，业务也比较复杂的情况。后面迭代开发应该好一些，如果业务比较复杂，一开始就搞很容易 delay 来着
【回复】回复 @CJ_John :对对对，我去年的项目delay 了半个月。我一个月学了加运用。根本来不及，最绝的还是我们技术总监只知道说你这个有问题，也不具体说哪里有问题。反正出了问题是我的锅。笑着活下去jpg 。想做大项目只给两个月不到的时间，也不知道哪里来的勇气，笑死。我实践的时候确实出现了子领域要加的情况，所以第一版成品出来的时候比较乱是真的。第二版才重新梳理处理了一遍。用ddd我感觉那个项目至少需要半年，不然那真的是毫无必要……
来一个道术合一:
会不会是自己理解和实践有问题，才说ddd不好呢[doge]，反正我用着挺顺手的。我觉得理解ddd有一个条件，就是必须要经历过一个mvc架构的，业务复杂的，已经处于后期的系统，这个时候让你去做一个迭代，你就知道痛苦了[脱单doge]，这个时候你去重构这个系统，你会发现你会自然而然的写成ddd的样子[嗑瓜子]

【回复】回复 @极海Channel :这个就像单体到微服务一样，会出现各种分布式的问题，但现在微服务还是大行其道，因为大多数人经历过单体的痛苦，所以选择微服务，或者是微服务才能找到工作。而mvc到ddd也是如此，只不过很少人经历过我说的那个经历，而更少的人有过重构的经历（公司很少会让你去重构一个系统，都是让你干活的），而ddd也不是工作必备，所以大部分人不理解ddd吧，反正我是这么认为的[嗑瓜子]
【回复】呃，不知道你是怎么理解微服务的，在我的理解中，微服务是一种软件架构风格，它将应用程序划分为小型、自治的服务，实现所谓的高内聚低耦合，高可用等等 而DDD则是一种软件设计思想和方法论，强调将软件设计围绕业务领域建模，DDD的目标是创建可维护、可扩展和易于理解的软件系统，它通常使用领域对象和领域服务来表达业务需求，将业务逻辑和技术实现分离开来。 所以我说微服务是ddd的实现方式之一，就是想说明微服务的架构设计、领域划分等，都是对ddd的方法论的一种实现，说的比较乱不知道您是否能理解我的意思。当然，对ddd的理解人人不同，也许我说的是不准确的甚至和您的完全相悖
【回复】可能，一个人不理解可能是他的问题，如果大部分人都难理解，那可能是方案有问题[思考]
源达郎:
我感觉DDD适用于对复杂业务的重构，这时候业务足够复杂且演进趋势已经相对稳定了，在出现业务概念不够内聚而导致变更困难时，可以考虑用DDD的思路去做重构。 除了海哥说的利于领域专家与研发沟通以外。DDD我认为的最大的好处是将业务复杂度和技术复杂度解耦(有点偏战术了)，技术一般来说相对通用一些，就算是新入职的同学看这部分代码都能很快上手，但是如果业务相对复杂时如果划分不合理，理解起来会非常痛苦（如果之前的维护人还跑路了的话...），不过这个也得接手同学懂DDD。 不过对于探索型的项目初期，需要快速验证的情况下DDD就真不合适，开发周期长不说，需求规划变来变去的(当然这个也有PM/决策人的锅，决策的人偷懒了，干活的就难受了)，可能下一个周期的迭代就把上一个周期的迭代给干掉了，这种情况用DDD完全就是折磨自己了。 大多数情况下感觉就用海哥说的OOD就好了，保证基本的隔离，不用严格和DDD的模式一样，这样未来往什么架构模式转换成本都不高，也能兼顾一开始的开发效率

【回复】说的太对了，我踏马现在做的项目就是初期，后面人都不知道还在不在，上来就是个DDD个锤子呵呵
【回复】架构就那三板斧的工作，流程梳理、聚合分层、开发验证。基本上可对应到戴明环的PDC，重构就是A，哈哈。思想、风格、模式就是各家经验总结某一部分的经验。需要大家自行放到某一个特定环节使用，而不是从头用到尾。
【回复】这里补充下，统一语言和TDD应该是可以帮助初期的模型构建
嗯好都行随便:
正在被这个折磨...每个专家对这玩意理解不一样 别的小部门的上层还根据自己的理解制定了所谓的军规要求大部门的所有开发必须遵从，还有人巡检。所以我们的代码经常会违反军规 一不小心就被通报。。关键是这些东西对于代码性能上来说没有任何提升 为了遵循每个人理解不同的规范给一线开发增加了不知道多少工作量[无语]

【回复】回复 @极海Channel : 代码规范只是军规的一部分 还有相当一部分的东西都是关于ddd架构的 比如最开始的军规是允许上层跨层调用下层（比如rest接口层跨过编排层直接调领域服务层）但是最近改成了不允许跨层调用 所以所有的方法全都要在编排层封装一个透传方法 性能一丢丢提升都没有 徒增工作量[doge]
【回复】领域驱动要领域专家支持的，如果是小系统最好别用。 如果非要用，还没有业务专家的支持，我认为是按盈利点去划分领域。核心领域就是赚钱的模块，次要盈利业务划分成一个领域，其他的非盈利拓展功能划分到一起。 这样划分好处是各部分代码职责明确，模块和业务一致，不再割裂，不过后续维护才能享受到便利。（拆分重组什么的）
【回复】回复 @极海Channel :军规里面比较正常的就是不让循环访问数据库和rpc 别的都是比较逆天的东西 写个工具类用threadlocal都要被拎出来提个issue 不知道咋想的[doge]
TimeCatcherYx:
我感觉DDD就是在简单的业务上面花里胡哨，企业项目优先稳定性，其次成本，其次性能，其次人力维护，很多企业技术难点绝对不是DDD能解决的，这需要大量的业务熟悉与市场了解，以及广泛的知识面，不是每个项目都是CRUD的，有的是基于内存管理的对象设计，比如一些复杂的通讯，交互怎么做的更好，所以，DDD就是在简单的业务上面没事找事，毕竟规范到达一定程度就可以了，太规范了你累大家也累，切记，自己只是个打工人，活干的好就行

【回复】ddd适合互联网行业，比如购物商城，每个模块都是产品的一部分，访问量超大但逻辑比较简单。企业级的业务系统是相对独立的，有非常复杂的逻辑和一致性要求，这时候单体或微服务就足够了，架构越简单越稳定，当然性能就一般般了，场景不同没有银弹。
【回复】[热词系列_知识增加]大佬
dlkla:
思想上的转变，从表驱动开发转变到模型驱动开发，让代码和业务概念可以较好的映射

【回复】这个是真的，面向数据库设计转化成面向对象设计[doge]
【回复】核心被UP忽略了，也就很好解释他遇到的挫折，然后错的是DDD就来了
SoyNeverGiveUp:
这玩意就是面试的时候用来装高大尚，吓唬没听过的人

【回复】很多人也意识到借鉴部分就好[妙啊]但是最终发现借鉴的部分和OOD无限接近
【回复】回复 @极海Channel :我也被折磨过，事实上DDD设计的系统好坏太过取决于架构师水平，如果碰上一个**架构师，整个项目不知道要折磨多少人
Nukazzz:
说个比较具体的问题，分层导致对象很多，而大部分情况是透传这个事。我们是通过mapstruct处理的，基本上，没有特殊逻辑的情况下定一个接口就可以。 我理解也确实不可能一个对象从头用到尾，domain和entity本来也存在实现上的区别。而domain和response生命周期也是不一样的，比方说业务上没有什么变化，但是api升级了版本。

【回复】分层模型没啥问题，但是我们当时设计的领域层太多了，而且最初抽象层次不一样导致很多变量名的类型都不一样，很难用mapstruct类的透，人工也大量的convert [妙啊] 当要排查某个字段丢失的情况，一大堆的convert直接疯掉
【回复】。。我这就是C端链路流量大 迁移成DDD后 gc频繁 对象多 佛了 写代码时候各种无脑convert从上到下穿透 感觉用的还是有问题
【回复】实际上真的做MVC也是要具体分VO DTO PO甚至有BO概念
Polyhedral:
哎，ddd最大的问题就是黑话太多，也没人来核对大家对黑话的理解是不是一样的。

Nukazzz:
我觉得DDD是很好的，有些细节问题要具体分析，整体思路我觉得没问题。属于更加结合业务的面向对象的模型设计。 只是说如果叠加上CQRS和Event Sourcing 这些pattern 以后会需要在代码上做一些适配。

【回复】回复 @极海Channel :是的，我觉得最核心的就是Domain的模型的充血设计，其余的一概可以按需剪裁
【回复】DDD的好体现在它OOA部分，我认为DDD想塞的东西太多[妙啊]Eric参与的系统都是上个世纪，而且全书就他一人作者，带太多理想化的主观想法，现在MSA照葫芦画瓢学不来[妙啊]
不会狗带的诚哥:
换大号回复了，以我司经验来看，开发人员低于500人的公司，业务线低于20条的没必要做DDD，本质上DDD是为架构治理服务的[doge]

【回复】推荐看下海哥看下我司的岗考书《大型商业银行金融科技管理》，你会有更高的视角和格局[doge]。
【回复】还要加一条，有一个统一的软件产品服务，业务线再多但主营业务是一个大型产品服务[脱单doge]，这才能玩得起ddd。
【回复】回复 @不会狗带的诚哥 : 这书看目录雄心壮志，看页数貌似有坑，书中建行的案例和我记忆中咨询同学建行信息化的实际情况，有差距不一定相符。但就我个人而言目录很有新引力
乘风虎:
一直以来都觉得DDD不太现实，增加开发很多理解成本，对开发要求和团队都不太友好，DDD本身就是偏学术的东西

晓晓汇汇:
本身，ddd就是一套理论，作者提出这个理论本身就是为了尝试解决业务复杂性。类似于面向对象提出并也没有成为软件工程的银弹。ddd本身也在不断的被完善，被落地，并且ddd也不是程序员 或者是架构师一个人的游戏，他是整个团队的事情。在实际的项目演进，到项目的结束，战略设计往往显得更为重要。有相当于一些团队在ddd落地之后会觉得受煎熬。那会不会是战略设计不充分又或者是压根就没有战略设计或者领域专家的参与导致的呢？

【回复】为什么不能用？本身软件架构和选型就应该遵循简单，合适，演化原则。你的业务场景和你的团队不适合用，不代表别人的业务和别人的团队用不了。
【回复】回复 @极海Channel :系不系很有道理
只有我不存在的__:
[笑哭]感觉互联网真是厉害，监控我在吧，最近正好就是在苦恼公司新架构师强行DDD造成原本稳定清晰的结构拆得稀碎，引入不少新问题，然后组员技术能力参差不齐，Bug急增，每期任务又紧张，弄得大家很累，而且任务也开始延期（本来我们好不容易由0到1熬到一个相对稳定的节奏，现在平白被打破）😩

【回复】回复 @村东搬砖 :属于是没有需求创造需求了，牛逼啊
【回复】[脱单doge]你就说是不是程序员更忙更重要了吧？要是一下子做好了，问题又少，还要架构师干嘛
【回复】[微笑]跟你情况一样,目前项目delay半年,而且已经全员满周加班一年了
数字随行:
ddd最大用途是统一沟通模型。尽量让IT实现逻辑和业务逻辑一致，而不是IT（业务、产品、架构三个岗位各自的上下文背景信息差距很大）按照自己的理解进行了转换或者平行替代。如果做过数据产品，会发现业务系统中的数据含义和处理逻辑与业务部门告知不一致的情况。

【回复】回复 @极海Channel :其实ddd，只要想成业务人员一起协作oo或者帮助核查oo的聚类是否还原了现实生活，逻辑是否合理。能找到愿意帮忙的领域专家才是核心。
【回复】很多人写的mvc是面向数据库编程…
【回复】面相存储和过程的编程转成领域OOP[妙啊]
我是天才琪露诺:
我实践的时候总搞不清有些东西应该怎么去划分，应该写在哪一层。有一些简单的东西按照ddd很难划分，感觉怎么划分都有道理，让我非常头疼

【回复】回复 @极海Channel :这个我和我同事也讨论过，反正最后我把和前段有关的（参数校验和返回值校验）写到controller里，其他的都写到service里[doge]
【回复】MVC也会很多人把业务逻辑写在Controller，能用啊，这个就很难约束[妙啊]
ViktorZhu:
其实ddd主要的就是充血以及问题拆分的一些思考[doge]结合一些软件工程设计模式以及很多东西配合有助于更深入的理解业务以及需求。感觉差不多了就可以可ddd🉑️不ddd了[doge]灵活切换。工程落地主要还是看效率 维护性 交付周期 扩展性还有成本其他都是扯蛋[doge]

【回复】回复 @极海Channel :卷起来[tv_doge]
【回复】DDD不必要套上框架，普通简单点的DDD思想设计就好了
【回复】回复 @Serly :是的[doge]我说的也是这个意思[doge]