DDD 从入门到放弃

2024 年了我终于放弃琢磨这玩意，几番尝试之后最终还是认清了现实。
理论虽好但不是包治百病，虽然能解决潜在问题，但前期投入无法令老板接受。
DDD 之难不在技术，而在于人。
仅通用语言和边界定义就足够让 DDD 绝了在绝大部分公司推行的路。
1.驱动设计？
老板：我们也要跟上时代，全面推行 DDD
冤种们：好好好！
老板：时间紧任务重，下周就上线有没有信心？先上线再迭代！
冤种们：………
2.领域拆分？
领域业务专家：我们有这玩意么？好像没有…那个谁，我认命你为领域业务专家，工资不变给你加个 title ，从此你就负责这个了。
冤种们：………
（第二天）
冤种们：专家我们来拆分定义下业务边界吧
“专家”：边界？我们的业务就是随客户需求不断进化，提升的！不要随便给自己定边界，那是限制自己的视野，我们的边界就是客户无边界，服务无边界！
冤种们：………
3.内部推行？
冤种 1:各位，目前我们先在这个子业务上尝试下 DDD 的模式，希望大家在这个模块上严格遵守边界规则，我们实行一段时间。
萌新 1:边界是啥？我这个需求好麻烦，看我一把梭哈。
萌新 2:好麻烦，这简直就是在降低我的效率，也是在降低公司的效率。这老梆子是不是折腾我们跟老板显绩效呢？我要跟老板反馈。整顿职场！
油条 1:麻烦，一把梭
油条 2:麻烦，一把梭
（一周后）
老板：实行已经一周了，我没有看到明显的优势在哪里，反而不少人反馈影响效率。还有不少业务部门反映跟客户变更服务受限制了，这和我们以用户为中心的文化不符，这个东西你不要搞了。
冤种：……… 老…老板英明。这就取消

abz

101 天前

单向依赖说一下，无论在域层面，模块层面，还是所谓的 ddd 分层层面，都要注意这个原则。至于战术层面，所谓聚合根就是高内聚的一种表现。ddd 的初衷是为了持续性的维护，它必然遵守高内聚低耦合这一最本质的原则。所谓的分层所谓的依赖倒置，单向依赖而已，这两个本质贯穿始终。仓库也是一样，不必纠结 save 还是 update.哪个习惯用哪个，只要和领域层不耦合在一起，保持领域层的稳定性就行。