nec*_*ace 13 domain-driven-design software-design microservices
在我阅读时,有两种模式可以定义一个微服务,按业务能力和子域.但我仍觉得它很模糊.我对这两种模式如何相互区分感到困惑.它们都围绕着涉及业务逻辑领域的活动.每个服务中的所有组件都足够小,可以相互打包而不会影响其他服务.有谁可以请你进一步解释这两个？
Chr*_*mon 17
评论者是对的 - 这里有一些主观定义.但是有一些原则和概念可以帮助推理不同的方法.
这不是严格的原始定义,但我认为参考康威定律可以更好地理解这种区别:
设计系统(广泛定义)的任何组织都将生成一种设计,其结构是组织通信结构的副本.
根据这种想法,反向康威机动进化了:
"逆向康威机动"建议改进您的团队和组织结构,以促进您所需的架构.理想情况下,您的技术架构将与您的业务架构显示同构.
反向Conway机动试图构建您的组织,以利用Conway定律来实现更好的系统设计.
通过对这些概念的理解,我们可以考虑按业务能力进行分解,以根据业务结构的方式指导系统设计.这回应了康威的定律.
这种方法的专家是有助于确保开发团队和业务结构单元之间的一致性.这可能会导致在考虑自动化系统之前将业务效率降低到系统设计之中.
领域驱动设计(DDD)提供了一套工具和方法来推理手头的基础域,以反映软件设计中对域的最佳可用理解,并随着对域的增长和变化的理解而发展软件设计.DDD战略模式指导创建上下文映射,它可以构成微服务分解的基础.
由此,我们可以根据对流程和信息流的分析,考虑按域分解来指导系统设计.
这种方法的优点在于它可以导致系统设计紧密地模拟正在发生(或需要发生)的现实.希望业务结构已经与此保持一致 - 但如果没有,它可以揭示现有业务组织结构中的低效率.
如果您对组织结构有影响,这可以成为利用Inverse Conway Maneuver的基础,并允许您发展软件,开发团队和业务部门以实现一致性.
如果不这样做,最终可能会引入系统设计与业务功能不一致的摩擦点.
实际情况是,这两种方法都不是相互排斥的 - 您可能最终会达成妥协,试图通过DDD流程揭示已经被理解的业务能力和业务能力.