2019-10-29您好，以我公司新启动的业务线“平安社区”为例，以安防设备为集成基础。安防设备和物联网平台却都是市场成熟厂家提供，划分为通用域；平安社区业务场景如人车双验、异常人员识别等个性化应用属于业务线的支撑域；人员数据、行为数据富有长期价值，这些视为核心域。如果未来在某个细分场景做到了领先且拥有市场壁垒，这样的业务也可能会从支撑域调整为核心域。
所以，核心域、通用域、支撑域的划分本质是公司战略方向的体现，DDD是从战略到战术角度来进行架构设计的方法。作者回复: 是这样的。
1 16
2019-10-16通用域和支撑域对应到企业系统是哪些呢？作者回复: 通用域是一些大家都需要用的通用系统，比如认证，权限等等，这类应用很容易买到，不需要做太多的定制化，没有企业特点。支撑域具有企业特性，但不具有通用性，比如数据代码类的数据字典等系统。
1 15
2019-10-22老师你好，关于问题空间和解决方案空间一直不是很理解，子域的划分属于问题空间，而限界上下文则属于解决方案空间。
但是这个所谓的问题空间和解决方案空间到底是啥？对于我们分析问题而言为何要划分这两种空间？作者回复: 你可以这么理解。问题空间的划分也就是子域的划分过程，实际上还是一个业务粗分过程，因为领域太大的话，你不方便对它进行分析和设计。
只有问题空间小到一定程度后，你才可以熟悉的定义解决方案空间，在这个比较小的空间内进行事件风暴，找出领域对象，构建聚合，划分限界上下文，建立领域模型，再进行微服务的设计，也就是一个解决方案的形成过程。 9
2019-11-26您好，我对领域驱动还算是入门比较早的了，看了您的文章后受益匪浅。总结和举例都非常到位，一句话表明了中心，不像其他的DDD课程，说得很官方。点个赞👍作者回复: 谢谢你的鼓励😄。
6
2019-11-05感谢老师非常深入浅出的桃树比喻。
我们公司是做车险鉴定（Insurance Assessment）的。
我们当时也初步开发了几个领域：
授权领域：这个因该是属于通用域，认证、权限、登陆都在里面；还有日志领域，专门为决策层制定月报告的一些功能；支付和审核领域，也是一个通用域，里面包含了创建账单和发票、收款等。
case领域，claim领域，assessment领域，repair领域等等，这几个是核心域，依次直接面对终端客户——保险方，索赔者，鉴定方，维修厂）
支撑域我还不是很理解，不知道在实际应用中，支撑域和通用域有哪些典型的有区别的例子。展开作者回复: 个人感觉区分支撑域和通用域的意义不是太大。
挖掘出核心域是有意义的，主要是明确战略重点，将重要的核心资源投入到核心域。
支撑域和通用域在战略上基本上是同级的，有时候两者会转换。 2 5
2019-12-10通用域在基础设施层 理解对吗作者回复: 不是的，通用域也是业务域，不过是可复用的业务域。跟基础设施层是不同的纬度。
4
2019-10-18有些领域边界特别模糊,不好划分,例如:某些子领域两边都靠,不知道怎么取舍作者回复: 看领域大小，不大的话可以考虑放在一个限界上下文内，做成一个微服务。比较大的话，可先做好聚合的边界，以后随时可以根据需要来拆分微服务。
4
2019-10-1613年以前基本是三层架构开发，13年后开始使用DDD，没系统的研究过，只是看了一些资料，我的理解是基于业务的属性，把原先的三层变成N个三层，相互间用接口或者API传输，不知道我这样理解对不对。作者回复: DDD包括战略和战术设计两个部分，战略设计完成领域建模，战术设计完成微服务设计。您说的应该属于战术设计的部分，DDD分层架构包括用户接入层、应用层、领域层和基础层四层，每层有不同的服务，职责不同。后面章节有详细介绍，请耐心等待。
4
2019-10-16终于理解了DDD是可以逐级细化的，大的DDD里应该是可以套小的DDD，也理解了核心域的意义。对于如何确定边界还存在疑问，希望在后面的课程中得到解答。
关于楼上朋友“子子域模型”的说法，其实只要定下一个大家都能理解的术语就行了，这跟DDD提倡的通用语言是一个道理。另外既然问题域可以逐级细化，那么在高层次看是子子域的范围，深入进去之后就成了“领域”，如果有必要的话也还可以在它下面再细分子域。不知这样理解对不对。作者回复: 非常正确。
4
2019-11-20问题域和解决方案域是不是重合的呢作者回复: 大多数是重合的，但是如果受外界因素影响比较大的话，可能会一个问题域对应多个解决方案域。也就是一个子域可能会有多个微服务。
3
2019-10-16这里没看限界上下文的概念，在桃树的例子中，细胞即为限界的上下文吗？还是说，器官，组织，细胞都是限界的上下文？作者回复: 你好，段拙言。还是你细心，不过不要纠结这里的限界上下文的概念，限界上下文是由它的语义边界来确定的。在DDD里面一个聚合可以是一个限界上下文，多个不同职能的聚合也可以组成为一个限界上下文，他们都在一个语义环境下。有的组织可能只有单一细胞，有的组织可能由多个不同功能的细胞组成的。我们重温一下生物课哈。由一种细胞所构成的均一组织。而由两种以上细胞构成的不均一的组织称为复合组织。特定功能（特定的语义环境）的组织基本上就可以对应到限界上下文。
2 3
2019-10-16对于领域问题来说，可以理解为。对一个问题不断的划分，直到划分为，我们熟悉的，能够快速处理的小问题。然后在对小问题处理在排列一个优先级。作者回复: 赞一个，理解的非常到位。划分到最小就是聚合，聚合之上就是限界上下文，根据限界上下文建立领域模型，然后设计微服务。
3
2019-12-16老师，公司是做sass bb2b商城，商品和订单与客户等级、客户紧密关联这样公司的核心域由多个域组成，我这样划分核心域感觉有问题
以下是领域划分：
1.用户域
2.商品域
3.订单域
4.库存域
5.租户域
6.租户应用
通用域：商品，库存，用户
核心域：用户域的客户+商品+订单
支撑域：租户，租户应用展开作者回复: 核心域的划分最好结合公司的战略和商业模式，一般来说跟公司收入或者能够给公司收入带来很大帮助的业务域是核心域，是企业与其他同业有区别的核心竞争力。当然一般电商来讲的话，客户，商品和订单是支撑核心业务的业务域，当然可能还会有一些营销域等，需要公司比较大的投入。而通用域和支撑域相对比较接近，区分的意义不算太大。
2- 2019-11-03领域跟子域是一个相对的概念，一个领域可能成为另外一个领域的子域，一个子域又可能成为另一个子域的领域。所以再确定领域的时候是不是得先确定好界限上下文？及确定范围呢？在一个范围内再谈领域子域。还有就是子域，到底划分到什么程度的时候就不用再划分下去，老师再文中指出要划分到聚合这里，就是说聚合就是最小的子域了吗？一个聚合对应一个微服务中的服务？
作者回复: 我在文中讲到了，在领域不断划分的过程中，领域会被细分为不同的子域，这个过程实际上是将问题范围不断缩小的过程。借用读者“密码123456”的总结，他认为：“对于领域问题来说，可以理解为，对一个问题不断的划分，直到划分为我们熟悉的，能够快速处理的小问题。然后在对小问题处理再排列一个优先级。”这个理解是很到位的。在领域细分到一定的范围后，我们就可以对这个子域进行事件风暴，为这个子域划分限界上下文，建立领域模型，然后可以基于领域模型进行微服务设计了。
虽然DDD没有明确说明子域和限界上下文的关系。我个人认为，子域的划分是一种比较粗的领域边界的划分，它不考虑子域内的领域对象、对象之间的关系和结构。子域的划分往往按照业务阶段或者功能模块边界进行粗分，其目的就是为了让你能够在一个相对较小的问题空间内，比较方便的用事件风暴来梳理业务场景。而限界上下文本质上也是子域，限界上下文是在明确的子域内，用事件风暴划分出来的。它体现的是一种详细的设计过程。这个过程设计出了领域模型，明确了领域对象以及领域对象的依赖等关系，有了领域模型，你就可以直接进行微服务设计了。
聚合是最小的业务单元，也是可以独立作为微服务的。 2 
2019-10-21一个聚合是不是就是一个业务流程中剥离出来的“业务环节”作者回复: 有一部分情况跟你说的业务环节类似。你可以这样打比方，若干个不同职责的人一起完成一件完整的事情，这些不同的人就是不同的实体或者值对象，完整的事情就是你业务环节里某一个完整业务逻辑。在聚合内将这些实体或值对象组织在一起完成共同的业务目标，这就是聚合。
2- 2019-10-16可不可以理解为通用域就是ddd分层中的基础设施层
作者回复: 基础设施层主要是系统运行需要的基础资源，比如数据库服务、总线、api网关等等。通用域是你业务的通用功能，比如用户权限系统。
2 
2019-10-16这个领域的划分还是采用的是分治思想，分治过后产生各个子域，由于关注度和作用不同，对这些子域进行标识为核心域、通用域以及支撑域作者回复: 是的，理解的很到位。
2- 2019-10-16“”我们可以根据业务关联度以及流程边界将保险领域细分为：承保、收付、再保以及理赔等子域” --- 根据业务关联度以及流程边界细分的方法能介绍下吗？
作者回复: 你好，huayu00。这一块的设计你可以参考传统的模块的设计方式。模块本身就是某类业务的功能聚合，具有一定的业务功能的内聚性。而对于很多业务场景来说，很多领域的边界就是流程的边界，比如商品、订单、货物，他们分别属于不同的流程，很自然的就形成了业务领域的边界。子域的划分需要结合公司自己的业务的情况，参考领域专家的意见来划分。
2 
2019-12-21老师您好，公司去年成立了中台部门，现在主要在做领域服务的沉淀，比如登录、权限、工作流。现在权限和工作流的通用服务中，还有些其他业务系统中都有用到员工和组织信息，其中员工和组织我理解是支撑领域服务。我有个困惑：如何保证支撑领域服务中的数据变化后，权限服务、工作流服务中用到的员工和组织信息也保持数据的一致性。作者回复: 你可以采用领域事件的方式，当源端数据发生变化的时候，如果目的端数据需要更新，就可以实现异步更新了。
1 1- 2019-11-24领域划分为子域需要根据公司的业务以及依赖领域专家的知识和经验。如果领域专家的经验不足，通常需要如何应对呢？另外领域专家之间达不成一致意见，陷入无止境的争论，这种情况下有如何应对？
作者回复: 1、领域专家经验不足就需要团队整体来讨论和决策，这个在很多新的创业的系统建设过程中应该很常见。领域模型也是需要多次迭代才能变得成熟和稳定。多做几次迭代才能摸索出完美的领域模型。
2、这个需要团队有相应的沟通规则。 1