微服务应该怎么弄
微服务的框架有很多 Java侧的dubbo,spring cloud(Netflix,alibaba),再用K8S去调度，扩容。
但这些都只是手段,或者按武侠思维来说，这只是招式。
而如何划分微服务显得更为重要，似乎这是内功。
核心思想
高度内聚（模型不能再拆）
作限界上下文 （清晰的边界）
怎么找–>
事件风暴工作坊，工作坊要求业务需求提出者和技术实施者协作完成领域建模。把系统状态做出改变的事件作为关键点，从系统事件的角度触发，提取能反应系统运作的业务模型。再进一步识别模型之间的关系，划分出限界上下文，可以看做逻辑上的微服务
一个个事件,找到共同作用的主体,把这些主体进行高内聚，抽象为不再划分的模型。
识别模型中的二义性（视角导致主体相似性,需要特别区别），让限界上下文划分更为准确
如何验收
两个目的出发：降低耦合、容易扩展，可以作为限界上下文评审原则
原则1，设计出来的限界上下文之间的互相依赖应该越少越好，依赖的上游不应该知道下游的信息。（被依赖者，例如订单依赖商品，商品不需要知道订单的信息）。
原则2，使用潜在业务进行适配，如果能在一定程度上响应业务变化，则证明用它指导出来的微服务可以在相当一段时间内足以支撑应用开发。
在微服务设计时，如果 domain service 需要通过一个 from 参数，根据不同的渠道做出不同的行为，这对系统的拓展是致命的。例如，用户服务对于访问他的来源不应该知晓；用户服务应该对订单、商品、物流等访问者提供无差别的服务。
因此，微服务的依赖关系可以总结为：上游系统不需要知道下游系统信息，否则请重新审视系统架构。
一些工具
C4 UML
多练习