微服务拆分过细的问题

微服务可能出现的问题之一，就是服务拆的太多，微服务拆多了就需要“治”，技术问题可以通过服务注册与发现“治”掉，但更多的业务问题很难被“治”掉。

如果一个团队缺少一个有影响力的业务架构师，这个问题将会变得更加严重。过多的承载着一部分业务含义的微服务散落下来，任意两个或几个微服务的组合似乎都可以解决一些业务上的问题，但这种组合是不可持续的。

同时如果没有业务架构师，这些看似合理的业务需求来自于pm或是bp，这件事情将会变得更加糟糕。终有一天整个技术团队会被包裹在一个找不到线头的网里，有人大喊一声“重构全链路”。

ddd不是目的，不要把简单的业务问题人为的技术复杂化。该在一起的服务就不要找理由拆了，因为他们在业务上就是一体的。先理解业务，再做抽象，单体难受了，想明白痛在哪里，再决定拆不拆。

有什么样的组织就有什么样的架构。有时候发现系统依赖关系很奇怪，一看组织结构就是这样的，康威定律依然适用，甚至是第一原则。妄图通过架构解决康威定律，但成本总会通过其他方式找回来。

缺少有影响力的业务架构师，业务流程与概念完全单方面来自于pm和bp，研发只是在pm和bp之后做业务建模。缺少合理的组织划分，导致体现康威定律的负面影响。

以上两者是微服务拆分过细之后的非技术角度必须要考虑的问题。