极客时间已完结课程限时免费阅读

02 | 领域、子域、核心域、通用域和支撑域：傻傻分不清？

02 | 领域、子域、核心域、通用域和支撑域：傻傻分不清？-极客时间

02 | 领域、子域、核心域、通用域和支撑域：傻傻分不清？

2019-10-16 欧创新 来自北京
《DDD实战课》
课程介绍

讲述：欧创新

时长13:06大小10.48M

你好，我是欧创新。
DDD 的知识体系提出了很多的名词，像：领域、子域、核心域、通用域、支撑域、限界上下文、聚合、聚合根、实体、值对象等等，非常多。这些名词，都是关键概念，但它们实在有些晦涩难懂，可能导致你还没开始实践 DDD 就打起了退堂鼓。因此，在基础篇中，我希望能带着你一起做好实践前的准备工作。
除此之外，我想说的是，这些名词在你的微服务设计和开发过程中不一定都用得上，但它可以帮你理解 DDD 的核心设计思想和理念。而这些思想和理念，在 IT 战略设计、业务建模和微服务设计中都是可以借鉴的。
那么，从这讲开始，我就会围绕以上这些 DDD 关键概念进行讲解，帮助你彻底理清它们与微服务的关系，了解它们在微服务设计中的作用。今天我们重点了解 DDD 的领域、子域、核心域、通用域和支撑域等重要概念。

如何理解领域和子域？

我们先看一下汉语词典中对领域的解释：“领域是从事一种专门活动或事业的范围、部类或部门。”百度百科对领域的解释：“领域具体指一种特定的范围或区域。”
两个解释有一个共同点——范围。对了！领域就是用来确定范围的，范围即边界，这也是 DDD 在设计中不断强调边界的原因。
在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，当领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。简言之，DDD 的领域就是这个边界内要解决的业务问题域。
既然领域是用来限定业务边界和范围的，那么就会有大小之分，领域越大，业务范围就越大，反之则相反。
领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。
我们知道，DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂度。那么面对错综复杂的业务领域，DDD 是如何使业务从复杂变得简单，更容易让人理解，技术实现更容易呢？
其实很好理解，DDD 的研究方法与自然科学的研究方法类似。当人们在自然科学研究中遇到复杂问题时，通常的做法就是将问题一步一步地细分，再针对细分出来的问题域，逐个深入研究，探索和建立所有子域的知识体系。当所有问题子域完成研究时，我们就建立了全部领域的完整知识体系了。
我们来看一下上面这张图。这个例子是在讲如何给桃树建立一个完整的生物学知识体系。初中生物课其实早就告诉我们研究方法了。它的研究过程是这样的。
第一步：确定研究对象，即研究领域，这里是一棵桃树。
第二步：对研究对象进行细分，将桃树细分为器官，器官又分为营养器官和生殖器官两种。其中营养器官包括根、茎和叶，生殖器官包括花、果实和种子。桃树的知识体系是我们已经确定要研究的问题域，对应 DDD 的领域。根、茎、叶、花、果实和种子等器官则是细分后的问题子域。这个过程就是 DDD 将领域细分为多个子域的过程。
第三步：对器官进行细分，将器官细分为组织。比如，叶子器官可细分为保护组织、营养组织和输导组织等。这个过程就是 DDD 将子域进一步细分为多个子域的过程。
第四步：对组织进行细分，将组织细分为细胞，细胞成为我们研究的最小单元。细胞之间的细胞壁确定了单元的边界，也确定了研究的最小边界。
这里先剧透一点聚合、聚合根、实体以及值对象的内容，我还会在 [第 04 讲] 和 [第 05 讲] 中详细讲解。
我们知道细胞核、线粒体、细胞膜等物质共同构成细胞，这些物质一起协作让细胞具有这类细胞特定的生物功能。在这里你可以把细胞理解为 DDD 的聚合，细胞内的这些物质就可以理解为聚合里面的聚合根、实体以及值对象等，在聚合内这些实体一起协作完成特定的业务功能。这个过程类似 DDD 设计时，确定微服务内功能要素和边界的过程。
这里总结一下，就是说每一个细分的领域都会有一个知识体系，也就是 DDD 的领域模型。在所有子域的研究完成后，我们就建立了全域的知识体系了，也就建立了全域的领域模型。
上面我们用自然科学研究的方法，说明了领域可以通过细分为子域的方法，来降低研究的复杂度。现在我们把这个话题再切换到业务领域，对比验证下，二者的细分过程是否是一致的。这里以我从事的保险行业为例。
保险是个比较大的领域，很早以前的保险核心系统把所有的功能都放在一个系统里来实现，这个系统就是我们常说的单体系统。后来单体系统开始无法适应保险业务的发展，因此保险公司开始了中台转型，引入分布式微服务架构来替换原来的单体系统。而分布式微服务架构就需要划分业务领域边界，建立领域模型，并实现微服务落地了。
为实现保险领域建模和微服务建设，我们可以根据业务关联度以及流程边界将保险领域细分为：承保、收付、再保以及理赔等子域，而承保子域还可以继续细分为投保、保全（寿险）、批改（财险）等子子域。
在投保这个限界上下文内可以建立投保的领域模型，投保的领域模型最后映射到系统就是投保微服务。这就是一个保险领域的细分和微服务的建设过程。
那么你可能会说，我不是保险行业的人，我怎么理解这个过程呢？我认为，不同行业的业务模型可能会不一样，但领域建模和微服务建设的过程和方法基本类似，其核心思想就是将问题域逐步分解，降低业务理解和系统实现的复杂度。

如何理解核心域、通用域和支撑域？

在领域不断划分的过程中，领域会细分为不同的子域，子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。
决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。还有一种功能子域是必需的，但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域。
这三类子域相较之下，核心域是最重要的，我们下面讲目的的时候还会以核心域为例详细介绍。通用域和支撑域如果对应到企业系统，举例来说的话，通用域则是你需要用到的通用系统，比如认证、权限等等，这类应用很容易买到，没有企业特点限制，不需要做太多的定制化。而支撑域则具有企业特性，但不具有通用性，例如数据代码类的数据字典等系统。
那为什么要划分核心域、通用域和支撑域，主要目的是什么呢？
还是拿上图的桃树来说吧。我们将桃树细分为了根、茎、叶、花、果实和种子等六个子域，那桃树是否有核心域？有的话，到底哪个是核心域呢？
不同的人对桃树的理解是不同的。如果这棵桃树生长在公园里，在园丁的眼里，他喜欢的是“人面桃花相映红”的阳春三月，这时花就是桃树的核心域。但如果这棵桃树生长在果园里，对果农来说，他则是希望在丰收的季节收获硕果累累的桃子，这时果实就是桃树的核心域。
在不同的场景下，不同的人对桃树核心域的理解是不同的，因此对桃树的处理方式也会不一样。园丁更关注桃树花期的营养，而果农则更关注桃树落果期的营养，有时为了保证果实的营养供给，还会裁剪掉疯长的茎和叶（通用域或支撑域）。
同样的道理，公司在 IT 系统建设过程中，由于预算和资源有限，对不同类型的子域应有不同的关注度和资源投入策略，记住好钢要用在刀刃上。
很多公司的业务，表面看上去相似，但商业模式和战略方向是存在很大差异的，因此公司的关注点会不一样，在划分核心域、通用域和支撑域时，其结果也会出现非常大的差异。
比如同样都是电商平台的淘宝、天猫、京东和苏宁易购，他们的商业模式是不同的。淘宝是 C2C 网站，个人卖家对个人买家，而天猫、京东和苏宁易购则是 B2C 网站，是公司卖家对个人买家。即便是苏宁易购与京东都是 B2C 的模式，他们的商业模式也是不一样的，苏宁易购是典型的传统线下卖场转型成为电商，京东则是直营加部分平台模式。
商业模式的不同会导致核心域划分结果的不同。有的公司核心域可能在客户服务，有的可能在产品质量，有的可能在物流。在公司领域细分、建立领域模型和系统建设时，我们就要结合公司战略重点和商业模式，找到核心域了，且重点关注核心域。
如果你的公司刚好有意向转型微服务架构的话，我建议你和你的技术团队要将核心域的建设排在首位，最好是有绝对的掌控能力和自主研发能力，如果资源实在有限的话，可以在支撑域或者通用域上想想办法，暂时采用外购的方式也未尝不可。

总结

领域的核心思想就是将问题域逐级细分，来降低业务理解和系统实现的复杂度。通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，而领域模型映射成系统就是微服务了。
核心域、支撑域和通用域的主要目标是：通过领域划分，区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。

思考题

请结合你所在公司的业务情况，尝试给业务做一个领域拆分，看看哪些子域是核心域，哪些子域是通用域和支撑域？
欢迎留言和我分享你的思考和疑惑，你也可以把今天所学分享给身边的朋友，邀请他加入探讨，共同进步。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 100

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
01 | 领域驱动设计：微服务设计为什么要选择DDD？
下一篇
03 | 限界上下文：定义领域边界的利器
 写留言

精选留言(124)

  • 祥敏
    2019-10-29
    您好，以我公司新启动的业务线“平安社区”为例，以安防设备为集成基础。安防设备和物联网平台却都是市场成熟厂家提供，划分为通用域；平安社区业务场景如人车双验、异常人员识别等个性化应用属于业务线的支撑域；人员数据、行为数据富有长期价值，这些视为核心域。如果未来在某个细分场景做到了领先且拥有市场壁垒，这样的业务也可能会从支撑域调整为核心域。 所以，核心域、通用域、支撑域的划分本质是公司战略方向的体现，DDD是从战略到战术角度来进行架构设计的方法。
    展开

    作者回复: 是这样的。

    共 4 条评论
    97
  • stg609
    2019-10-22
    老师你好，关于问题空间和解决方案空间一直不是很理解，子域的划分属于问题空间，而限界上下文则属于解决方案空间。 但是这个所谓的问题空间和解决方案空间到底是啥？对于我们分析问题而言为何要划分这两种空间？

    作者回复: 你可以这么理解。问题空间的划分也就是子域的划分过程，实际上还是一个业务粗分过程，因为领域太大的话，你不方便对它进行分析和设计。 只有问题空间小到一定程度后，你才可以熟悉的定义解决方案空间，在这个比较小的空间内进行事件风暴，找出领域对象，构建聚合，划分限界上下文，建立领域模型，再进行微服务的设计，也就是一个解决方案的形成过程。

    41
  •  海大
    2019-12-10
    通用域在基础设施层 理解对吗

    作者回复: 不是的，通用域也是业务域，不过是可复用的业务域。跟基础设施层是不同的纬度。

    24
  • vivi
    2019-10-16
    通用域和支撑域对应到企业系统是哪些呢？

    作者回复: 通用域是一些大家都需要用的通用系统，比如认证，权限等等，这类应用很容易买到，不需要做太多的定制化，没有企业特点。支撑域具有企业特性，但不具有通用性，比如数据代码类的数据字典等系统。

    共 2 条评论
    24
  • 密码123456
    2019-10-16
    对于领域问题来说，可以理解为。对一个问题不断的划分，直到划分为，我们熟悉的，能够快速处理的小问题。然后在对小问题处理在排列一个优先级。

    作者回复: 赞一个，理解的非常到位。划分到最小就是聚合，聚合之上就是限界上下文，根据限界上下文建立领域模型，然后设计微服务。

    20
  • Catwell
    2019-10-16
    13年以前基本是三层架构开发，13年后开始使用DDD，没系统的研究过，只是看了一些资料，我的理解是基于业务的属性，把原先的三层变成N个三层，相互间用接口或者API传输，不知道我这样理解对不对。

    作者回复: DDD包括战略和战术设计两个部分，战略设计完成领域建模，战术设计完成微服务设计。您说的应该属于战术设计的部分，DDD分层架构包括用户接入层、应用层、领域层和基础层四层，每层有不同的服务，职责不同。后面章节有详细介绍，请耐心等待。

    共 3 条评论
    18
  • Geek_a91670
    2019-10-18
    有些领域边界特别模糊,不好划分,例如:某些子领域两边都靠,不知道怎么取舍

    作者回复: 看领域大小，不大的话可以考虑放在一个限界上下文内，做成一个微服务。比较大的话，可先做好聚合的边界，以后随时可以根据需要来拆分微服务。

    17
  • 宝宝太喜欢极客时间了
    2019-11-03
    领域跟子域是一个相对的概念，一个领域可能成为另外一个领域的子域，一个子域又可能成为另一个子域的领域。所以再确定领域的时候是不是得先确定好界限上下文？及确定范围呢？在一个范围内再谈领域子域。还有就是子域，到底划分到什么程度的时候就不用再划分下去，老师再文中指出要划分到聚合这里，就是说聚合就是最小的子域了吗？一个聚合对应一个微服务中的服务？

    作者回复: 我在文中讲到了，在领域不断划分的过程中，领域会被细分为不同的子域，这个过程实际上是将问题范围不断缩小的过程。借用读者“密码123456”的总结，他认为：“对于领域问题来说，可以理解为，对一个问题不断的划分，直到划分为我们熟悉的，能够快速处理的小问题。然后在对小问题处理再排列一个优先级。”这个理解是很到位的。在领域细分到一定的范围后，我们就可以对这个子域进行事件风暴，为这个子域划分限界上下文，建立领域模型，然后可以基于领域模型进行微服务设计了。 虽然DDD没有明确说明子域和限界上下文的关系。我个人认为，子域的划分是一种比较粗的领域边界的划分，它不考虑子域内的领域对象、对象之间的关系和结构。子域的划分往往按照业务阶段或者功能模块边界进行粗分，其目的就是为了让你能够在一个相对较小的问题空间内，比较方便的用事件风暴来梳理业务场景。而限界上下文本质上也是子域，限界上下文是在明确的子域内，用事件风暴划分出来的。它体现的是一种详细的设计过程。这个过程设计出了领域模型，明确了领域对象以及领域对象的依赖等关系，有了领域模型，你就可以直接进行微服务设计了。 聚合是最小的业务单元，也是可以独立作为微服务的。

    15
  • 拙言
    2019-10-16
    这里没看限界上下文的概念，在桃树的例子中，细胞即为限界的上下文吗？还是说，器官，组织，细胞都是限界的上下文？

    作者回复: 你好，段拙言。还是你细心，不过不要纠结这里的限界上下文的概念，限界上下文是由它的语义边界来确定的。在DDD里面一个聚合可以是一个限界上下文，多个不同职能的聚合也可以组成为一个限界上下文，他们都在一个语义环境下。有的组织可能只有单一细胞，有的组织可能由多个不同功能的细胞组成的。我们重温一下生物课哈。由一种细胞所构成的均一组织。而由两种以上细胞构成的不均一的组织称为复合组织。特定功能（特定的语义环境）的组织基本上就可以对应到限界上下文。

    共 3 条评论
    13
  • Geek_e8f4b0
    2020-06-18
    发现文章有点晚最近才看到，很有启发，tks，我有一个疑问：一个子域是不是等于一个限界上下文边界，如果不是，那么如何划分子域，子域与限界上下文又是什么关系，因为你后续相关文章都是提高由事情找实体和值对象，根据实体和值对象找聚合根形成聚合，聚合s+限界上下文+一些微服务的拆分原则构成一个微服务。那子域在其中并没有启动拆分的作用。

    作者回复: 最近在准备书的内容，书里面对这一部有详细说明，我就直接复制过来了。 在DDD中包括问题域和解决方案域两个不同的维度。问题域主要从业务视角来考虑，完成从领域到子域的分解，而解决方案域则主要从技术实现的角度，通过划分限界上下文和采用DDD战术设计完成微服务拆分和落地。“子域”和“限界上下文”这两个概念分别从不同的视角，构建起了DDD 处理业务复杂度的根基。 个人认为“子域”和“限界上下文”在大多数情况下是一对一或者一对多的映射关系。从实践角度，我们可以这样理解，我们不妨将业务领域的分解拆分为两个阶段：从领域到子域的粗粒度的分解和从子域到限界上下文的技术实现级的分解。有时候企业的业务领域非常庞大，不太方便用事件风暴对整个领域构建领域模型。所以在领域建模之前，我们先根据业务流程边界或者功能集合等要素，将庞大的领域分解成若干个大小合适的子域，然后根据子域属性划分为核心子域、通用子域和支撑子域。当领域分解到足够小后，我们就可以在这些子域内开展事件风暴，划分限界上下文完成领域建模。 在对不同属性子域构建领域模型时，我们可能会有不同的关注点，比如在通用子域构建领域模型时，我们会更多的关注领域模型的抽象和标准化，以便实现企业级复用，这种设计方法与中台的业务建模方法是一致的。当然，如果你的领域足够小的话，我们就没必要进行从领域到子域的分解和属性归类了，你可以直接开展事件风暴，直接划分限界上下文，完成领域建模。按照这种分解方式，如果子域和限界上下文边界刚好一致，那它们就是一对一的关系，而如果在一个子域内还可以划分为多个限界上下文，那我们最终得到的就是一对多的映射关系。需要注意的是，有些通用子域构建出来的领域模型往往会因为复用的需要，可能会跨多个不同的其他业务子域。 限界上下文本质上就是子域，只不过它会更多的考虑领域对象的语义边界和技术实现细节。限界上下文的划分体现的是一种更为详细的设计过程，这个过程划分了业务的上下文语义边界，完成了领域模型，明确了领域对象以及领域对象之间的依赖关系等。我们依据限界上下文和领域模型就可以完成微服务设计和落地了。

    13
  • marker
    2019-11-26
    您好，我对领域驱动还算是入门比较早的了，看了您的文章后受益匪浅。总结和举例都非常到位，一句话表明了中心，不像其他的DDD课程，说得很官方。点个赞👍

    作者回复: 谢谢你的鼓励😄。

    11
  • huaweichen
    2019-11-05
    感谢老师非常深入浅出的桃树比喻。 我们公司是做车险鉴定（Insurance Assessment）的。 我们当时也初步开发了几个领域： 授权领域：这个因该是属于通用域，认证、权限、登陆都在里面；还有日志领域，专门为决策层制定月报告的一些功能；支付和审核领域，也是一个通用域，里面包含了创建账单和发票、收款等。 case领域，claim领域，assessment领域，repair领域等等，这几个是核心域，依次直接面对终端客户——保险方，索赔者，鉴定方，维修厂） 支撑域我还不是很理解，不知道在实际应用中，支撑域和通用域有哪些典型的有区别的例子。
    展开

    作者回复: 个人感觉区分支撑域和通用域的意义不是太大。 挖掘出核心域是有意义的，主要是明确战略重点，将重要的核心资源投入到核心域。 支撑域和通用域在战略上基本上是同级的，有时候两者会转换。

    共 3 条评论
    12
  • TH
    2019-10-16
    终于理解了DDD是可以逐级细化的，大的DDD里应该是可以套小的DDD，也理解了核心域的意义。对于如何确定边界还存在疑问，希望在后面的课程中得到解答。 关于楼上朋友“子子域模型”的说法，其实只要定下一个大家都能理解的术语就行了，这跟DDD提倡的通用语言是一个道理。另外既然问题域可以逐级细化，那么在高层次看是子子域的范围，深入进去之后就成了“领域”，如果有必要的话也还可以在它下面再细分子域。不知这样理解对不对。
    展开

    作者回复: 非常正确。

    8
  • Geek_88604f
    2019-11-20
    问题域和解决方案域是不是重合的呢

    作者回复: 大多数是重合的，但是如果受外界因素影响比较大的话，可能会一个问题域对应多个解决方案域。也就是一个子域可能会有多个微服务。

    6
  • FelixFly
    2019-10-16
    这个领域的划分还是采用的是分治思想，分治过后产生各个子域，由于关注度和作用不同，对这些子域进行标识为核心域、通用域以及支撑域

    作者回复: 是的，理解的很到位。

    6
  • 谭方敏
    2020-02-21
    我的理解是领域的划分需要根据所在公司的战略及商业模式这个原则来进行，拆分的方法可以用通用的逻辑工具：MECE（完全独立，相互穷尽）到最后，核心域，通用域，支撑域有很重要的现实意义，这样决定在不同域投入的IT资源的比例，另外对于核心域的把握尤为关键，一般开始有两个原则：1）实打实赚钱的，能产生现金流的，足球主攻手得分王；2）能加快现金流转的，虽然不赚钱，但是起到助攻作用的，比如足球助攻手，至于通用域和支撑域的区分就不显得那么重要了，如果真要说点啥的话，通用域就是可以复用程度比较高的域，而支撑域就是默默付出的域。
    展开

    作者回复: 😄，比喻的很贴切。

    6
  • 微笑
    2019-12-16
    老师，公司是做sass bb2b商城，商品和订单与客户等级、客户紧密关联这样公司的核心域由多个域组成，我这样划分核心域感觉有问题 以下是领域划分： 1.用户域 2.商品域 3.订单域 4.库存域 5.租户域 6.租户应用 通用域：商品，库存，用户 核心域：用户域的客户+商品+订单 支撑域：租户，租户应用
    展开

    作者回复: 核心域的划分最好结合公司的战略和商业模式，一般来说跟公司收入或者能够给公司收入带来很大帮助的业务域是核心域，是企业与其他同业有区别的核心竞争力。当然一般电商来讲的话，客户，商品和订单是支撑核心业务的业务域，当然可能还会有一些营销域等，需要公司比较大的投入。而通用域和支撑域相对比较接近，区分的意义不算太大。

    共 3 条评论
    4
  • 白开水有三种味道
    2019-10-21
    一个聚合是不是就是一个业务流程中剥离出来的“业务环节”

    作者回复: 有一部分情况跟你说的业务环节类似。你可以这样打比方，若干个不同职责的人一起完成一件完整的事情，这些不同的人就是不同的实体或者值对象，完整的事情就是你业务环节里某一个完整业务逻辑。在聚合内将这些实体或值对象组织在一起完成共同的业务目标，这就是聚合。

    4
  • 起风了
    2019-10-16
    ​领域 简单理解就是指特定的 范围 或 区域，那是不是就可以认为领域其实就是我们要做事情的范围或区域，领域模型我认为就是 设计思想, 也可以理解为 解决方案, 比如现在需要将清结算系统进行微服务拆分，我们现在要做的就是来分析清结算整个系统的业务块，例如清分或结算 , 然后来梳理业务边界，可以简单的认为 领域 就是要在这个范围内要解决的业务问题域。通俗来将就是我们要解决问题的范围即可称之为领域。 2.2 子域 ​在了解 领域 后可以知道，业务问题域其实就是 子域, 子域 可以分为 清分 和 结算 等，也可以将 清分子域 作为领域，在进行分析清分业务块的业务进行 分域。我举的例子可能比较小，大家可以对应理解领域为 中台服务, 其中有 用户子域 , 交易子域 , 风控子域 , 清洁算子域 等。然后可以在清洁算子域中建立领域模型(清洁算业务模型)，在进行子子域的划分，可以把每个子域中建立领域模型。 2.3 核心域 ​在之前已经将 领域界限 规定到了 清洁算系统， 子域包含 清分子域 , 结算子域, 对账子域，不同的人看到系统的核心并不一样，可能有人认为 清分子域是核心域，也会有人认为 对账子域是核心域，这个就是本身所处的位置和职责不同，导致 核心域不同。 2.4 通用域 ​通用域 就很好理解了, 反映到了我们的代码上就可以将公共服务作为 通用域 。这个公共服务其实就是全部子域中的其中一个子域。 例如鉴权系统。 2.5 支撑域 ​支撑域 我认为所存在的意义是为了支撑其他系统而存在但又不所有子域都可以使用的通用系统，都可以称之为 支撑域。 2.6 界限上下文 ​界限上下文 映射到业务层可以理解为是业务的边界或者系统的边界。 我理解的对嘛？
    展开

    作者回复: 基本没什么问题。领域模型是由若干个领域对象以及业务行为组成的，也就是我们常说的业务模型。

    4
  • 技术修行者
    2020-10-31
    我们目前的解决方案大概分为四层：基础设施层、技术中台、业务中台、业务客户。我负责技术中台部分，向上层提供一些通用的基础服务，例如数据访问服务、消息队列服务、邮件服务等。 我有几个问题想请教一下。 1. 作为技术中台，其实很难和具体业务产生关联的，那么我们应该如何使用DDD呢？ 2. 站在整个解决方案的高度看，我理解我现在做的就是通用域，那如果站在技术中台的角度，我应该怎样确定核心域呢？核心域是否一定要和业务相关联？
    展开

    作者回复: DDD一般主要还是用于业务领域的边界和建立领域模型。而技术中台主要还是用于支撑业务中台的开发和运行，很难建立技术中台的领域模型，个人感觉似乎不太适合用DDD的方式来设计。如果您的技术中台适合建立领域模型，那就可以用DDD设计方法。 DDD的核心域、通用域以及支撑域是放在企业整体来考虑的，主要还是偏业务领域的属性划分。

    3