领域驱动设计(domain driven design)战略篇之二 Bounded Context

最新推荐文章于 2024-07-28 12:03:35 发布

even_he

最新推荐文章于 2024-07-28 12:03:35 发布

阅读量3.9k

点赞数 1

文章标签： domain driven desgin 领域驱动设计 ddd

本文链接：https://blog.csdn.net/abchywabc/article/details/81900794

版权

本文探讨了领域驱动设计中Bounded Context的概念，强调其在系统拆分和避免模型错误认识中的关键作用。通过实例分析，指出忽视Bounded Context可能导致的沟通成本和系统复杂性，并阐述了ddd对Bounded Context的定义。

摘要由CSDN通过智能技术生成

之前的一篇文章谈了战略ddd的重要性与Bounded Context这个概念，最近在油管上看到一个2017年关于domain driven design的演讲。如下
the good parts
感觉与自己现在讲的主题十分相关，正好在这里展开说一下。
他认为Bounded Context可能是ddd中最重要的概念。而悲剧地是ddd的社群可能更倾向于讨论战术方面的各种设计模式，他顺便也吐槽了一下ddd这本书的章节编排。
我也很赞同他的看法。具体说一下这两点。

1. ddd的战略部分容易被忽略

还是摆出这张图
ddd
学习ddd的人在开始可能更热衷于战术层面设计模式。如上图里repository, specification, aggregate那部分概念，以及在代码层面如何实现它们。
本人自己也是如此，在读《domain driven design》时基本把战略部分给跳过了。而且战略部分也是书的最后几章。读完了战术篇的部分，就已经觉得
这里写图片描述
也由于此书对读者的极其不友好，读到最后几章时基本气力已经耗尽。(如下图，全书共17章，Bounded Context居然到了14章才登场。)
ddd 章节
然而,在实际的项目中，如果我们只是去讨论如何实现这些设计模式，那会是很可笑的。最重要的是如何实现项目的需求。虽说如此，本人在写博客时，还是先从ddd的战术开始写的。原因大概有这么几点
1.1 这反映了自己对ddd的认知历程。本人一开始也深陷ddd战术的话题，而对战略层面的东西基本选择跳过。所以认