领域驱动设计
文章平均质量分 83
解读《领域驱动设计 软件核心复杂性应对之道》
一步一台阶
跬步行千里,滴水聚江海!
展开
-
解读《领域驱动设计 软件核心复杂性应对之道》(九)
前面3章给出了战略层面上应用领域驱动设计的很多原则和技术。在一个大的、复杂的系统中,可能需要在一个设计中综合运用几种策略。原创 2022-10-26 09:00:00 · 984 阅读 · 1 评论 -
解读《领域驱动设计 软件核心复杂性应对之道》(八)
这章的标题是“大型结构”。其实这章主要在讲“系统大到一定程度后,我们应该怎样整体的去管理和看待这个系统”。如何保证大型系统各个部分能统一朝着正确的方向发展。感觉这章直接叫“战略设计”,可能更好理解一些。比如,“远交近攻”就是战略,但具体应该先“远交”哪些国家,先“近攻”哪些国家,可能大家的观点就会有差异了。但不管有多大的差异,都要在“远交近攻”这个大框架下去制定具体战术。原创 2022-10-24 08:00:00 · 908 阅读 · 0 评论 -
解读《领域驱动设计 软件核心复杂性应对之道》(七)
上章我们讲到领域层被分割成一个个BOUNDED CONTEXT,构建出了CONTEXT MAP,并介绍了各个CONTEXT的关系。做任何事情,都要抓住主要矛盾,进行领域驱动设计也是。我们需要通过精炼,得到CORE DOMAIN(核心领域)。围绕核心领域展开分析。核心领域可能包含几个CONTEXT,也肯能只包含一个CONTEXT,甚至可能只是CONTEXT的一部分(如上章讲的SHARED KERNEL)。 精炼是把一堆杂乱在一起的组件分开的过程,以便通过某种形式从中提取出最重要的内容。就像蒸馏原创 2022-10-17 07:30:00 · 985 阅读 · 0 评论 -
解读《领域驱动设计 软件核心复杂性应对之道》(六)
随着功能越来越多,系统会越来越复杂。当系统大到一定程度,就需要对系统进行拆分。系统大到一定程度,还需要多个团队共同维护。这部分讲的是更宏观层面的设计,所以叫战略设计。第14章讲的是“分”,即如何对结构进行划分,各个结构之间用BOUNDED CONTEXT分隔开,划分之后,如何处理各个部分之间的关系;第15章讲的是精炼,是指要突出主要矛盾,对划分出的各个部分,重点关注核心领域的那部分;第16章讲的是“合”,即如何保证大型系统各个部分能统一朝着正确的方向发展。原创 2022-10-12 11:54:27 · 503 阅读 · 0 评论 -
解读《领域驱动设计 软件核心复杂性应对之道》(四)
如何让我们设计的框架,在后期更容易维护和修改,本章给出来了一些参考思路。原创 2022-10-03 12:29:26 · 779 阅读 · 0 评论 -
解读《领域驱动设计 软件核心复杂性应对之道》(五)
软件设计,很重要的一个方法就是“借鉴”,下面两章重点介绍了,如何通过借鉴分析模式和设计模式,来进行领域驱动设计。原创 2022-10-09 15:29:44 · 726 阅读 · 0 评论 -
解读《领域驱动设计 软件核心复杂性应对之道》(一)
这本书共分为4部分。有几个重点的章节。作者也在绪论里提了,可以选读。作者在书中多次提到,领域驱动设计并不是要求一开始就设计出完美的系统。我们需要不断重构、不断精进。可以是对老系统进行领域驱动改造。也可以新系统直接使用领域驱动去设计。但谁也不能保证新系统在设计后,不会再次优化架构。本书只是在你优化时,给你提供一些指导思想罢了。重要的是思维方式,而不是最后的形态。因为架构总是在演进的,而方法论却可以一直陪伴我们。原创 2022-09-16 15:40:23 · 1205 阅读 · 0 评论 -
解读《领域驱动设计 软件核心复杂性应对之道》(三)
重构就是在不改变软件功能的前提下重新设计它。好的模型不是一次就构建出来的,需要不断的重构。重构是无止境的,但也不是随机的。这部分阐述了一些指引我们保持正确方向的建模原则。我们可以利用这些原则改进我们的设计。原创 2022-09-26 17:29:32 · 295 阅读 · 0 评论 -
解读《领域驱动设计 软件核心复杂性应对之道》(二)
DDD的理念是一种理想化的思维方式。在项目落地的时候,还要参考目前已成型的框架的支持情况。说白了,就是理想很丰满,现实很骨感。鉴于目前技术框架的限制,我们在做DDD设计时,不得不在一些地方做出一些细微的取舍。原创 2022-09-26 09:57:42 · 805 阅读 · 0 评论