这周跟大家分享3个收获，如下：

我们设计一个服务往往有两难。

第一难，我们事先对服务的边界没有进行很好的划分，结果在落地的过程中，大家反复争论具体功能的归属。

第二难，由于对业务的了解不够深入，我们要么设计不足，导致同一个服务有很多版本；要么服务过度设计，实现了一堆永远用不上的功能。

服务边界的划分和功能的抽象设计是核心。服务边界确定了这个服务应该“做什么”，抽象设计确定了这个服务应该“怎么做”。

产品经理在做什么？

大量零散的原始需求经过梳理和关联，变成一系列有序的业务流程，以及流程里面的业务步骤（业务步骤也称之为业务节点），然后产品经理把这一系列的业务流程和业务节点以用户界面的方式定义出来，总的来说，产品经理定义了系统的外表。

这些产出对于用户了解系统长什么样子，应该如何使用这个系统，以及系统是否满足他们的需求来说，是足够的，但对于开发者来说还远远不够，因为他们需要能进一步看到系统的内部结构。

所以还需要架构师，业务架构师，技术架构师。

拆分系统有两种方式，一、按照业务流程，二、按照业务域。

如果按照业务流程来拆分系统模块，那么，有多少业务流程，就有多少个系统模块，这个对应关系比较直接，但实现起来很困难。

如果按照业务域来拆分，有多少业务领域，就有多个系统模块，流程中的业务节点按照业务域的不同，可以划分到不同的系统模块。

建议：肯定是按照业务域来拆分。比如如果按照业务流程，选择商品、下订单、在线支付是在一个系统里面，如果按照业务域来拆分那就是商品系统、订单系统、支付系统。

参考资料：《架构实战案例解析》

----END----

这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。