小机灵鬼|干货速来！透彻剖析微服务架构设计模式，深入开发Java有奇效( 六 )
从业务能力到服务一旦确定了业务能力 ， 就可以为每个能力或相关能力组定义服务 。 下图显示了 FTGO应用程序从能力到服务的映射 。 某些顶级能力（如会计记账能力）将映射到服务 。 在其他情况下 ， 子能力映射到服务
上图显示的服务仅仅是定义架构的第一次尝试 。 随着我们对应用程序领域的了解越来越多 ， 它们可能会随着时间的推移而变化 ， 特别是架构定义流程中的一个重要步骤是调查服务如何在每个关键架构服务中协作 。 例如 ， 你可能会发现由于过多的进程间通信而导致特定的分解效率低下 ， 导致你必须把一些服务组合在一起 。 相反 ， 服务可能会在复杂性方面增长到值得将其拆分为多个服务的程度
根据子域进行服务拆分领域驱动设计是构建复杂软件的方法论 ， 这些软件通常都以面向对象和领域模型为核心 。 领域模型以解决具体问题的方式包含了一个领域内的知识 。 它定义了当前领域相关团队的词汇表 ， DDD 也称之为通用语言（Ubiquitous language） 。 领域模型会被紧密地映射到应用的设计和实现环节 。 在微服务架构的设计层面 ， DDD 有两个特别重要的概念 ， 子域和限界上下文领域驱动为每一个子域定义单独的领域模型 。 子域是领域的一部分 ， 领域是 DDD 中用来描述应用程序问题域的一个术语 。 识别子域的方式跟识别业务能力一样：分析业务并识别业务的不同专业领域 ， 分析产出的子域定义结果也会跟业务能力非常接近 。 FTGO 的子域包括：订单获取、订单管理、餐馆管理、送餐和会计 。 正如你所见：这些子域跟我们之前定义的业务能力非常接近 。 DDD 把领域模型的边界称为限界上下文（bounded context） 。 限界上下文包括实现这个模型的代码集合 。 当使用微服务架构时 ， 每一个限界上下文对应一个或者一组服务 。 换一种说法 ， 我们可以通过 DDD 的方式定义子域 ， 并把子域对应为每一个服务 ， 这样就完成了微服务架构的设计工作 。 图 2-9 展示了子域和服务之间的映射 ， 每一个子域都有属于它们自己的领域模型 。
DDD 和微服务架构简直就是天生一对 。 DDD 的子域和限界上下文的概念 ， 可以很好地跟微服务架构中的服务进行匹配 。 而且 ， 微服务架构中的自治化团队负责服务开发的概念 ， 也跟 DDD 中每个领域模型都由一个独立团队负责开发的概念吻合 。 更有趣的是 ， 子域用于它自己的领域模型这个概念 ， 为消除上帝类和优化服务拆分提供了好办法
上帝类的处理上帝类是在整个应用程序中使用的全局类 。 上帝类通常为应用程序的许多不同方面实现业务逻辑 。 它有大量字段映射到具有许多列的数据库表 。 大多数应用程序至少有一个这样的上帝类 。 Order 类是 FTGO 应用程序中上帝类的一个很好的例子 。 这并不奇怪：毕竟 FTGO 的目的是向客户提供食品订单 。 系统的大多数部分都涉及订单 。 如果 FTGO 应用程序具有单个领域模型 ， 则 Order 类将是一个非常大的类 。 它将具有与应用程序的许多不同部分相对应的状态和行为 。 下图显示了使用传统建模技术创建的 Order 类的结构
Order 类具有与订单处理、餐馆订单管理、送餐和付款相对应的字段及方法 。 由于一个模型必须描述来自应用程序的不同部分的状态转换 ， 因此该类还具有复杂的状态模型 。 在目前情况下 ， 这个类的存在使得将代码分割成服务变得极其困难
推荐阅读
- 操作系统|干货分享：优麒麟系统上的硬盘读写性能测试
- 北京|北京晚高峰拥堵指数突破年度极值！司机灵魂拷问：我干嘛要开车？
- 尼康|索尼官微抖机灵“翻车”：国际空间站宇航员一直用尼康相机
- 比特币|2021年巴菲特股东大会15条干货出炉：承认卖错股票、给比特币定调
- 任豪|任豪发文回应言论争议 抖机灵发言令人费解 日本人看了都一脸懵
- 干货｜全球上市的十大PD-1/L1用药信息大盘点！2020版
- 超多干货！新能源的“蔚来”疾驰而至 固态电池凭什么这么能打？
- 充满正能量的人生哲理语录，精辟透彻，让人幡然醒悟！
- 马未都是如何看待王刚在鉴宝现场砸藏品的他的回答很透彻
- 板绘鼻子详细画法干货详解！让人感到惊艳的鼻子绘製方法！