zupeng

因为这是一个demo项目，为了简化，很多常规业务流程没有做（比如用户注册绑定手机、订单支付、订单取消等等）。demo核心业务逻辑主要集中在意向单和司机的匹配上，这正是Intention领域的逻辑，很多方法都在Intention这个根对象上面体现出来了。 https://github.com/JoeCao/qbike/blob/master/intention/src/main/java/club/newtech/qbike/intention/domain/core/root/Intention.java 你看所有的候选司机都是在这个根对象里面的，就是为了方便做匹配的业务逻辑，这是一个典型的充血模型。 对于其他的业务逻辑，可以自行扩展。分析哪些方法在根对象中，主要是用“Event Stoming”、“贴身职责”的方式来进行。

就是用Keynote画的

Feign我不太熟悉，你可以帮忙做一些修改PR。

      

@Xiaobaxi 好的，欢迎转载。

@SDLyu 已改，非常感谢

@xishuixixia 本文采用 CC BY 3.0 CN协议 进行许可。 可自由转载、引用，但需署名作者且注明文章出处。 有什么问题可以邮件联系我。

@xingzhefeng 你的担忧很有道理，我在文章里面也说了，这个世界是纯数学构建的，有一天我们可以用公式来精确的计算任何一个逻辑。就像围棋，我们把每个变化都算清楚就是围棋之神了， 但是现在我们还做不到，只能通过剪枝和蒙特卡洛加上深度学习去寻求近似解。 而面向对象、DDD本身是经验性的，不能严格证明。但是他是我看到的目前最接近业务逻辑近似解的方案了。

@yingzidd12 本文采用 CC BY 3.0 CN协议 进行许可。 可自由转载、引用，但需署名作者且注明文章出处。 有什么问题可以邮件联系我。

@magichan 实际上除非是图形处理这种消耗CPU的业务，我们90%以上的业务的性能瓶颈都在IO上，也就是存储上。这种情况下，你用容器创建更多的业务逻辑的微服务进程也是徒劳，并不能解决性能问题。但是如果BC和存储在一起，你反而可以有针对性的发现有性能瓶颈的BC，然后采用分区分片的方式，或者直接用NoSQL去存储热点的数据。不需要所有的数据库都跟着一起变化，充分发挥微服务独立松耦合的特性，去解决水平扩展。