正如我所读，有两种模式可以通过business capability和subdomain来定义一个微服务。但我仍觉得它很模糊。我对这两种模式如何相互区分感到困惑。它们都围绕着涉及业务逻辑领域的活动。每个服务中的所有组件都足够小，可以相互打包而不会影响其他服务。有谁可以请你进一步解释这两个？
答案 0 :(得分：9)
评论者是对的 - 这里有一些主观定义。但是有一些原则和概念可以帮助推理不同的方法。
它不是严格的原始定义，但我认为参考Conway's Law可以更好地理解这种区别：
任何设计系统（广泛定义）的组织都将产生一种设计，其结构是组织通信结构的副本。
根据这种想法，Inverse Conway Maneuver进化了：
反向Conway机动＆＃39;建议改进您的团队和组织结构，以促进您所需的架构。理想情况下，您的技术架构将与您的业务架构显示同构。
Inverse Conway Maneuver试图构建您的组织，以利用Conway法则来实现更好的系统设计。
通过对这些概念的理解，我们可以考虑按业务能力进行分解，以根据业务结构的方式指导系统设计。这回应了康威定律。
这种方法的专家是有助于确保开发团队和业务结构单元之间的一致性。这可能会导致在考虑自动化系统之前将业务效率降低到系统设计中。
域驱动设计（DDD）提供了一套工具和方法来推理手头的基础域，以反映软件设计中对域的最佳可用理解，并随着对域的理解的增长而发展软件设计和变化。 DDD战略模式指导Context Map的创建，它可以构成微服务分解的基础。
由此，我们可以根据对流程和信息流的分析，考虑按域分解来指导系统设计。
这种方法的优点在于它可以导致系统设计紧密地模拟正在发生（或需要发生）的现实。希望业务结构已经与此保持一致 - 但在没有的情况下，它可以揭示现有业务组织结构中的低效率。
如果您对组织结构有影响力，这可以成为利用Inverse Conway Maneuver的基础，并允许您发展软件，开发团队和业务部门以实现一致。
如果你不这样做，你最终可能会引入摩擦点，而系统设计与业务能力不一致。
现实情况是，这两种方法都不是相互排斥的 - 您可能最终会达成妥协，试图平衡与业务能力的对齐，因为它们已经被理解，并且问题域通过DDD流程显示出来。
答案 1 :(得分：0)
业务能力不能反映组织结构的一对一关系。表示企业的工作（其具有的功能），而没有指定将如何实现它们。组织结构是“如何” /实施的一部分。
如果您的业务能力图是根据您的组织结构来构造的，则应该对其进行更仔细的评估，除非您当然先创建业务能力图，然后相应地更改组织结构。
我已经处理了域和业务功能。它们基本上是相同的，具体取决于您的工作水平。
答案 2 :(得分：-1)
但是业务能力并不与组织结构直接相关。业务能力是由组织单位完成的，但是我认为这是两件事。