2019-11-18之前2个月前，要做微服务，当时不了解是啥，就感觉好厉害。然后按照业务划分。最后做成的结果，就像文中说的。大单体变成小单体。，高度耦合。做的自己都快看不下去了。作者回复: 在没有用DDD之前，我们也是这么干的^_^。
2 5
2019-12-22欧总，你好，我在拆分微服务时遇到一个好纠结的问题，例如三个微服务，分别是入库微服务，出库微服务，库存微服务，而库存微服务主要提供两种能力，一是：查询库存，二是：更新库存数据，而入库服务与出库服务都会在自己的业务逻辑内调用库存服务的“查询库存”和“更新库存”方法，为了避开分布式事务的场景，我们现在用的方案是在入库，出库的操作时，通过接口形式调用库存服务的“查询库存”接口方法，但当要在入库或出库操作步骤中要更新库存数据时，我们为了保证入库操作与库存更新在同一个事务内执行，达到事务一致性，我们通过引用库存服务对应的jar包形式，在入库和出库的服务代码中调用库存服务模块的“更新库存”的service方法来实现的，请问对于这种场景，你们有没有遇到，如果有，那你们是如何处理的？请指教，谢谢。作者回复: 感觉你这种方案也没法解决数据一致性的问题。一般来说产生数据一致性的主要原因在数据库，也就是说一个写成功，另一个写失败。虽然JAR包和业务执行逻辑在一起了，但是由于数据库是分开的，在数据库层面还是无法保证数据的一致性的，所以虽然它们在一个jar包中，应该还是需要采用分布式事务的。
我们没有遇到过你说的场景，但是这个场景应该在电商里面是非常常见的，比如查询商品数量，商品售出后，更新商品库存数据。 2 1
2019-11-18老师，是不是不通过DDD拆分的微服务基本就是大单体到小单体的拆分？作者回复: 如果还是原来的架构模式，不做解耦的话，应该还是小单体模式。我也是找了好久才找到了DDD这个方法，不知道还有没有其它更好的方法。
1 1
2019-11-22在同一个微服务内的应用层使用领域层的服务时，数据传递建议使用哪种类型的对象呢？是用DTO还是DO？
如果因为性能问题，讲应用层对领域服务的调用从微服务内调用改为跨微服务调用（例如RESTful或者RPC），那么调用接口传递数据是否使用DTO比较合适？作者回复: 应用层与领域层之间是DO。
微服务之间用DTO比较合适。
2019-11-20那随着业务的快速发展，如果某一个微服务遇到了高性能挑战，需要将部分业务能力独立出去，我们就可以以聚合为单位，将聚合代码拆分独立为一个新的微服务。
领域层拆了，应用层怎么拆成两个？作者回复: 应用层也可以拆的。但是应用层的服务如果跨聚合组合，先需要解耦，从微服务内调用改成跨微服务调用。然后将聚合封装出来的应用服务拆分。
2019-11-18消息总线是连接各位服务的关键吗？还是直接http或rpc就行？消息总线该如何设计呢？老师会讲讲这部分吗作者回复: 消息总线比较常见，这个专栏里就不讲了。