Miss 置顶2019-12-26git地址以及示例代码讲解预计元旦前后更新，敬请期待！感谢等待、追更！ 2 8
2019-12-02故不积跬步，无以至千里。不积小流，无以成江河。建议老师会说话就出书。这个课程比较全面，包含价值观和方法论两个层面的内容。一是课程订阅者可以作为工具书温习复习，二是私人癖好想收藏记录一下。作者回复: 谢谢你的建议。等好了告诉你哈。
5
2019-12-02从专栏出来一篇没有落下的跟到现在，时间真的好快！
收获良多，算是入了ddd的门，重术(战术)更要重道(战略)，后续打算把ddd分享给身边的人，至少一起码的人要有所了解，有相同的语言，才能一起聊下去
感谢老师，江湖再见！！！作者回复: 江湖再见！
1 5
2019-12-03讲的很不错，想了解一下幂等和事务方面在ddd实现中有什么思路或经验作者回复: 就DDD来说，它是没有幂等的方案的，需要我们通过设计来实现。原本想在第20节加一个幂等的议题的。
你可以在不同阶段进行幂等性处理，如使用Token（UUID）、分布式锁、去重表等方式。
可通过Token或全局唯一ID确定请求的唯一性：根据业务生成一个全局唯一ID,在调用接口时会传入该ID,接口提供方会从相应的存储系统比如Redis中去检索这个全局ID是否存在,如果存在则说明该操作已经执行过了,将拒绝本次服务请求;否则将相应该服务请求并将全局ID存入存储系统中,之后包含相同业务ID参数的请求将被拒绝。
可使用Redis分布式锁解决资源并发竞争的情况，获取唯一请求；
可使用去重表保证数据库数据唯一：适用于在业务中有唯一标识的插入场景。比如在支付场景中,一个订单只会支付一次,可以建立一张去重表,将订单ID作为唯一索引。把支付并且写入支付单据到去重表放入一个事务中,这样当出现重复支付时,数据库就会抛出唯一约束异常,操作就会回滚。这样保证了订单只会被支付一次。 2
2019-12-02第一次学习这种几乎纯理论的课程确实很考验耐心，幸运的是老师这种讲课方式很适合我，全部学习了，收获很大，感谢！作者回复: 谢谢你的耐心陪伴。
2
2019-12-11老师，git项目地址什么时候可以整理好发出来啊作者回复: 正在准备中，等整理好了发出来。
1- 2019-12-10老师的代码什么时候放出来啊。
作者回复: 最近比较忙哈，还需要一点时间。等好了告诉你。
1 
2019-12-09很希望老师能多出一些领域分析实战的相关课程，四色原型，用列，事件风暴这些相关设计作者回复: 谢谢建议。后续考虑考虑。
1
2019-12-04欧老师的课程内容富有层次，注重整体。
不能一下子都吸收，后序要反复实践、归纳整理，如此循环才能跨过坑和大海。作者回复: 谢谢，建议来回多看几遍。
1
2020-01-01talk is cheap show me the code作者回复: 马上就有代码详解上新了。
2019-12-24这个很重要是跨过！
2019-12-17粗劣看完了,实在都是干货,值得反复多看几遍.等老师的代码demo出来再对照着看相信收获更大.
2019-12-07另一个问题帮忙回复下？战术设计完成映射，战略设计完成领域建模，这个回答太笼统了，你文章里面写过了，占用您点时间，帮忙看一下另一个问题呢，感谢作者回复: 已回复。因为不知道你的聚合是如何得来的，不知是否回答清楚？
2- 2019-12-07具体也就是，是放在战略设计阶段还是放在战术设计阶段的“建立领域模型与微服务模型的映射关系”这一过程中
作者回复: 战术设计来完成映射。战略主要是领域建模。
- 2019-12-07老师，您好，现在在做一个开放平台（包括openapi）的系统，在战略设计的时候，有个地方有点疑惑，主要是，用户申请调用接口的权限和回调接口的权限这块，我是给统一画到“权限”限界上下文中了，该权限上下文中包含“接口权限申请、修改、删除”聚合，“回调接口权限申请、修改、删除”聚合，此处在战略设计阶段是否要抽象出“权限的申请、修改、删除”这一聚合（为接口和回调接口权限的公共抽象）。也就是该限界上下文中是只包含两个聚合（接口权限和回调接口权限），还是三个聚合（权限、接口权限、回调接口权限），根据第十二节中业务场景分析“找出领域事件、实体和命令等领域对象，支撑领域建模。”，感觉分成三个是更好的选择，望老师指正，在线急等。。。
作者回复: 这两个聚合实体之间业务行为差异大不？不大的话，我建议你将这两个聚合合并，变成一个领域模型。如果差异实在太大，还是分成两个聚合比较好。如果是三个聚合，三个聚合的实体对象如何聚合在一起？是把公共的实体独立出来吗？
5 
2019-12-04在微服务拆分的时候遇到一个问题。比如订单实体中有一个用户id字段来表示买家是谁。那假如在界面上显示订单的时候需要显示买家的昵称，而且如果用户修改了昵称，希望该用户所有未完成的订单上都显示修改后的昵称。并且如果用户存在未完成的订单则不允许用户删除自己的账户。这个时候如果把用户服务和订单服务拆分的话，应该怎样保证数据的一致性呢？拆分之后，用户服务的删除操作依赖于订单服务告诉它该用户是否存在未完成的订单。而订单服务又依赖于用户服务去获取用户的昵称。这样就相互依赖了。不知道老师怎么解决类似的问题呢？作者回复: 如果用户和订单在一个微服务内，就需要应用服务来协调和校验。如果是微服务之间，可以通过BFF微服务或者各自的应用服务来编排和校验。
- 2019-12-03感谢欧老师以后再见！
作者回复: 再见，有问题咱们还可以探讨。
2019-12-03想了解一下，fatcory 和 repository 都可以构建 domain object，这两个分别是什么作者回复: 仓储是专门与数据库打交道的，用于持久化数据。而工厂是用于复杂聚合的实体数据初始化，简单的聚合可以通过聚合根直接在构造函数中完成初始化，而复杂聚合则交给工厂来完成聚合实体数据的初始化，工厂不参与业务逻辑处理。两者差不多是一前一后的关系。
5
2019-12-03感谢，一定还会反复学习这门课程。作者回复: 多看几遍，仔细体会和思考，确实是感受到DDD的思想的。
2019-12-03感谢作者回复: 感谢陪伴