2019-11-08接触ddd的概念也蛮多年了，确实如老师所说，微服务的兴起让大家有自然的想起了ddd。但是要将ddd落地，不知道在代码层面如何去分层是最让人困扰的。以java web开发为例，controller，dao，service怎么和应用服务，领域服务，聚合等对应起来呢？老师能不能展示一下框架里面怎么去组织这些概念，这样作为研发人员会比较好理解。ddd的经典三本书里面就是缺少这种东西，互联网小厂由于能力有限很难将其理解和落地。一直期待一门课从代码层面开始自底向上来讲解ddd，反而会更好理解。一直反复讲ddd的好处，感觉浮在表面。作者回复: 其实DDD的核心思想是在于划分领域边界从而来解耦。我认为领域模型才是DDD在微服务设计的关键，只有构建了边界清晰的领域模型的边界，才有可能设计出高质量的微服务。在建立领域模型后，微服务内部可以用DDD战术设计方法，传统的开发方法也不是不可以，有时候在性能方面表现更优秀。
后面我有一节专门讲解这些对象之间是如何协作的，另外也有一讲来介绍DDD的代码目录结构和模型。 2 7
2019-11-09DDD是中台、微服务的产品经理作者回复: 比喻很形象！
1 5
2019-11-09很多人提到代码，其实代码方面我觉得可以看看 Domain modeling made functional 这书。 3
2019-11-08看来要公布Github的仓库了，要不怎么是实践篇@@@作者回复: DDD用于微服务设计的关键就是先建立领域模型，有了边界清晰的领域模型，才能设计出高质量的微服务。在微服务设计时不能脱离领域模型来谈微服务。它们两者之间是必不可少的前后贯通的关系，可能开发人员只关心用DDD来做微服务的开发，并不关心领域建模。领域建模就是DDD的战略实战。而且这种战略设计和分析过程比战术设计更重要。
1 2- 2019-11-08建议老师，多讲讲怎么做的领域、聚合根、实体的划分，讲讲实施层面怎么做的？而不是直接抛出你最终的结果，我觉得这才是要学DDD的精髓。看到现在知道了很多名词，但是依然并不知道DDD具体如何实施，具体场景下拿什么依据作为划分和聚类的参考~
建议对于文章中的例子，比如您举的保险类例子，可以多补充些业务背景，这样才能在战术层面搞明白实施和落地的流程，而不是悬浮在半空中~作者回复: 这一节信息量比较大，后面小的案例里有介绍。
2 
2019-11-24聚合内的实体都是通过聚合根来进行访问的，这个有没有相关的例子，感谢老师作者回复: 聚合根内会定义引用的实体，在聚合根内部直接使用引用的实体属性或者方法就可以了。
这些实体的方法会被封装成领域服务或者应用服务。外界不需要关心这些实体内的属性或者方法实现了。 1
2019-11-11看了11个课程了，最大的疑问就是怎么划分？ 老师每次都拿出你已经划分好的领域，感觉很空泛，领会不到精髓作者回复: 这一节的内容有点多，没有做过细的分析，你可以看下一节哈。第12节有详细的领域建模分析过程。
1
2020-01-27欧老师，新年好。
我有个问题，我们公司有电商、erp、crm等产品。
目前构建的服务，针对电商的不同端做支撑，可以很容易的实现复用，但是领导希望我们构建的服务可以为公司所有产品做支撑。
想请教下，为电商构建的服务有必要为erp、crm这类产品做准备吗？
erp、crm这类产品我们认为和电商的业务差距太大，基本不具备复用的可能。作者回复: 按照中台建设的思路当然需要放在整个企业来考虑复用的。你们这几类产品可以根据领域模型，找出领域模型中的共同的聚合，求同存异，来设计可复用的领域模型。
2020-01-02那我又看懵了，我们也有订单服务，商品服务，用户服务等等，那我们这也是中台服务咯？作者回复: 中台和平台的差异建议再看一下第九节。
2019-12-19代码可以参考这个 https://github.com/JoeCao/qbike
2019-12-19老师，我们也在做中台转型，进行探索中。
其实前面的业务分析边界划分，这个确实需要长时间积累和专业。
但是如果后面业务有变动，我们之前做的分析，比如各种图，各种表格，如何演进。是否有更好的演进方式。维护演进我有点摸不着。作者回复: 后续的变更可以以表格为基础来进行，一个微服务一个表格。服务和实体级的变动在一个表格内演进就可以了。如果涉及到不同微服务的聚合重组，在不同微服务表格之间变动就可以了。小的业务变动不需要重新来做事件风暴，重新设计图。
3
2019-11-25看到这一章，我突然有一个新的想法，但不知道对不对。中台和中间件类似，但不同的是，中间件是解决技术层面上的问题，中台是解决业务层面上的问题。比如说，中间件kafka用来提供异步、解耦、削峰功能；中台用户用来提供用户、权限、认证功能作者回复: 从复用的角度来看，目标是一致的，都是将公共的能力沉淀，然后复用。
2019-11-15老师，可不可以用代码示例一下，每集都听了几回，但还是不理解作者回复: 前面主要是基础知识，后面会有一些代码方面的示例。到服务和方法级。
2019-11-15转型的话，感觉自顶向下和自底向上都需要
自顶向下确定的是目标，但是整个推倒重来一般都是不现实的（而且大部分情况下还需要保证服务稳定和对用户不可见），只能逐步演进
自底向上是认清现实，找到一条通向目标的路作者回复: 是的，要根据企业情况具体分析。
2019-11-14对核心中台和通用中台有点疑惑，说下自己的理解：核心中台就是和业务强相关的，通用中台就是，即使不是保险业务，换成金融业务，也可以用；
请问是这个意思吗？作者回复: 是的。通用的话，企业内能被很多地方复用也算。
2019-11-13欧老师好，我说下我对ddd在中台建设中所起作用的看法，不当之处请指点；ddd为中台所涉及到的领域模型梳理提供了方法指引，并对微服务的划分提供了参考标准；但有了这些对一个业务中台的建设还不是完备的；因为中台提供了业务能力服用层，也就是说抽象出了可服用的公共能力，但每个使用该能力的场景是不一样的，这样在该能力上的定制需求的满足是就出现了，这就需要中台有扩展能力，来适应这些需求；所以中台建设不单是微服务的合理拆分，可扩展能力的架构设计也是中台建设的关键；作者回复: 是这样的。
- 2019-11-13划分清楚业务域，是战略设计中的核心，因为只有划分清楚业务域，才会构建出良好的领域对象、聚合、聚合根、限界上下文等，所以，划分清楚业务域是核心中的核心，望老师答复，是否正确
作者回复: 理解正确。
2019-11-12欧老师你好
领域类型中“命令”怎么理解？CreatePerson和GetPersonInfo是两个类？DDD提倡使用充血模型，那么Person实体（同样也是聚合根）里会有针对person的CURD方法。CreatePerson和GetPersonInfo里去调用Person里的相应方法？作者回复: 命令是一种业务操作或行为，通常会被设计成应用服务或者领域服务，在没有确定是哪种服务之前，统一用命令来表示。实体的方法都在自己的类里面来实现，然后通过聚合根引用来调用。聚合根是一种特殊的实体，它的方法你可以在它的实体内来实现，然后放在领域服务类里面来封装，也可以直接放在领域服务类里来实现。一个领域服务可以是一个类，也可以一个聚合内所有的领域服务放在一个领域服务类里。你可以根据自己的场景来设计，要尽量避免一个类里面的代码过多。
2019-11-11中台是不是就是微服务之后的产物，之前的微服务太凌乱了，需要中台来聚合一下，是这个意思吗？作者回复: 不是的哦。中台是从业务能力复用的角度考虑的。也就是说将可复用的业务能力做成中台。而微服务只是一种架构，业务变成应用的一种架构方式。
- 2019-11-11示例中是直接划分好的领域跟聚合，老师能不能讲一下领域划分确定的过程以及聚合划分确定的过程，为什么这样划分一个聚合是合理的
作者回复: 在12节的领域建模里有详细说明。