分解模式 - 按业务领域分解模式划分微服务

本文说明如何经过业务领域分析和DDD将大型复杂的应用程序划分为一组微服务。html

#场景架构

使用微服务架构开发一个大型复杂的应用程序,咱们须要将应用程序细致,合理地分解为一组松散耦合的微服务。微服务架构的目标是经过实现持续交付/部署来加速软件开发。框架

#目标微服务

  • 架构必须稳定;
  • 服务必须高内聚 - 服务应该实现一小组强相关的功能;
  • 服务必须符合开闭原则 - 将一同变动的内容打包在一块儿,以确保每一个更改仅影响一个服务;
  • 服务必须松耦合 - 每一个服务均可以在不影响客户端的状况下更改实现;
  • 服务应该是可测试的;
  • 每项服务都小到足以由“两个披萨”团队开发,即一个6-10人的团队;
  • 负责一个或多个服务的每一个团队必须是自治的 - 团队可以在与其余团队尽可能少的协做下,来开发和部署他们的服务。

#方法 经过领域驱动设计(DDD),设计与 子域 相对应的服务。DDD经过分析问题空间和业务逻辑,将应用程序定义为域。域由多个子域组成。每一个子域对应于业务的不一样部分。测试

子域可分为如下几类:设计

  • 核心类 - 业务的关键差别化因素和应用程序中最有价值的部分;
  • 支持类 - 与业务有关,但与差别化无关;这些能够在内部实施或外包;
  • 通用类 - 与业务无关,理想状况下可使用现成的软件实现。

#例子htm

一个在线商店的子域包括:对象

  • 产品目录
  • 库存管理
  • 订单管理
  • 交货管理

相应的微服务架构中,每个子域将对应一个微服务。blog

#优势开发

  • 因为子域相对稳定,所以具备稳定的体系结构;
  • 开发团队能有效隔离业务逻辑和技术框架;
  • 服务具备高内聚和松耦合。

#问题

如何识别子域? 识别子域须要了解业务。经过分析业务及其组织结构来识别不一样的专业领域,从而识别子域。这个过程一般须要不断迭代。

识别子域的好思路是:

  • 组织结构 - 组织内的不一样分组或部门可能对应于不一样子域;
  • 高阶域模型 - 子域一般具备关键域对象。

#相关模式

<a href="http://www.cnblogs.com/yorkwu/p/9273548.html" target="_blank">微服务架构风格</a>

相关文章
相关标签/搜索