大奖18dj18vip-大奖18dj18娱乐官网

【腾讯云】境外1核2G服务器低至2折,半价续费券限量免费领取!

大奖18dj18vip

大奖18dj18vip 门户 教程 电脑网络 查看内容

阿里高级技术专家:整洁的应用架构“长”什么样?

2020-1-21 16:38| 发布者: 虚拟主机评测| 查看: 58| 评论: 0

摘要: 作者张建飞是阿里巴巴高级技术专家,入司6年,他创建了COLA。希望可以探索一套切实可行的应用架构规范,这个规范不是高高在上的纸上谈兵,而是可以复制、可以理解、可以落地、可以控制复杂性的指导和约束。本文详述 ...

作者张建飞是阿里巴巴高级技术专家,入司6年,他创建了COLA。希望可以探索一套切实可行的应用架构规范,这个规范不是高高在上的纸上谈兵,而是可以复制、可以理解、可以落地、可以控制复杂性的指导和约束。本文详述了他对COLA的升级迭代。

很多同学不止一次和我反馈,我们的系统很混乱,主要表现在:

  • 应用的层次结构混乱:不知道应用应该如何分层、应该包含哪些组件、组件之间的关系是什么;
  • 缺少规范的指导和约束:新加一段业务逻辑不知道放在什么地方(哪个类,哪个包)、应该起什么名字比较合适?

解决这些问题,正是我创建COLA(http://github.com/alibaba/COLA)的初心之一——试图探索一套切实可行的应用架构规范,这个规范不是高高在上的纸上谈兵,而是可以复制、可以理解、可以落地、可以控制复杂性的指导和约束。

自从COLA诞生以来,我收到了很多的意见和建议。同时,我自己在实践过程中,也发现COLA 1.0的诸多不足,有些设计是冗余的并不是很有必要,而有些关键要素并没有囊括。譬如,我最近在思考的应用架构核心和复杂业务代码治理就是对COLA 1.0的反思。

结合实践中的探索和对复杂度治理持续的思考,我决定对COLA进行一次全面的升级,于是有了现在的COLA 2.0。

从1.0到2.0,不仅仅是数字的简单变化,更是架构理念和设计理念的升级,其主要变动点包括:

  • 新架构分层:Domain层不再直接依赖Infrastructure层。
  • 新组件划分:对组件进行了重新定义和划分,加了新组件,去除了一些老组件(Validator,Convertor等)。
  • 新扩展点设计:引入了新概念,让扩展更加灵活。
  • 新二方库定位:二方库不仅仅是DTO,也是Domain Model的轻量级表达和实现。

新架构分层

在COLA 1.0中,我们的分层是如下图所示的经典分层结构:

在COLA 2.0中,还是这些层次,但是依赖关系发生了变化,Domain层不再直接依赖Infrastructure层,而是引入了一个Gateway的概念,使用DIP(Dependency Inversion Principle,依赖倒置)反转了Domain层和Infrastructure层的依赖关系,其关系如下图所示:

这样做的好处是Domain层会变得更加纯粹,完全摆脱了对技术细节(以及技术细节带来的复杂度)的依赖,只需要安心处理业务逻辑就好了。

除此之外,还有两个好处:

1. 并行开发:只要在Domain和Infrastructure之间约定好接口,可以有两个同学并行编写Domain和Infrastructure的代码。2. 可测试性:没有任何依赖的Domain里面都是POJO的类,单元测试将会变得非常方便,也非常适合TDD的开发。

新组件划分

模块和组件的定义

首先,先明确一下组件(Component)这个概念的定义,组件在Java中(或者说在本文中),其范围就是Java的包(Package)。

还有一个词叫模块(Module),组件和模块这两个概念是比较容易发生混淆的。比如在《实现领域驱动设计》中,作者就说:

If you are using Java or C#, you are already familiar with Modules, though you know them by another name. Java calls them packages. C# calls them namespaces.

他认为Module是Package,我认为这个定义容易造成混淆。特别是在使用Maven的时候,在Maven中,Module是一个Artifact,通常是一个Jar而不是Package。比如COLA Framework就包括如下四个Module:

  1. CIMAl; border: none; line-height: 21px; font-family: Arial; background: url("http://images.51cto.com/images/art1105/images/0.gif") -498px -70px repeat-y scroll transparent; color: inherit; padding: 0px 3px 0px 10px !important; margin: 0px !important; list-style-position: outside !important;"><modules> 
  2.     <module>cola-common</module> 
  3.     <module>cola-core</module> 
  4.     <module>cola-extension</module> 
  5.     <module>cola-test</module> 
  6. </modules> 

的确,Module和Component这两个概念很相近,很容易造成混淆。比如,在StackOverflow上有一个提问【1】,就是问Module和Component之间区别的。获得最高赞的答案是通过Scope来区分的。

The terms are similar. I generally think of a "module" as being larger than a "component". A component is a single part, usually relatively small in scope.

这个回答和我的直觉反应是一致的,即Module比Component要大。根据以上信息,我在此对Module和Component进行一下定义说明,在本文中,都会遵照如下的定义和Notation(表示法)。

  • 模块(Module):和Maven中Module定义保持一致,简单理解就是Jar。用正方体表示。
  • 组件(Component):和UML中的定义类似,简单理解就是Package。用UML的组件图表示。

一个Moudle通常是由多个Component组成的,其关系和表示法如下图所示:

COLA 2.0的组件

在COLA 2.0中,我们重新设计了组件,引入了一些新的组件,也去除了一些旧组件。这些变动的宗旨是为了让应用结构更加清晰,组件的职责更加明确,从而更好的提供开发指导和约束。

新的组件结构如下图所示:

这些组件各自都有自己的职责范围,组件的职责是COLA的重要组成部分,也就是我们上面说的“指导和约束”。这些组件的详细职责描述如下:

二方库里的组件:

  • api:存放的是应用对外的接口。
  • dto.domainmodel:用来做数据传输的轻量级领域对象。
  • dto.domainevent: 用来做数据传输的领域事件。

Application里的组件:

  • service:接口实现的facade,没有业务逻辑,可以包含对不同终端的adapter。
  • eventhandler:处理领域事件,包括本域的和外域的。
  • executor:用来处理命令(Command)和查询(Query),对复杂业务,可以包含Phase和Step。
  • interceptor: COLA提供的对所有请求的AOP处理机制。

Domain里的组件:

  • domain:领域实体,允许继承domainmodel。
  • domainservice: 领域服务,用来提供更粗粒度的领域能力。
  • gateway:对外依赖的网关接口,包括存储、RPC、Search等。

Infrastructure里的组件:

  • config:配置信息相关。
  • message:消息处理相关。
  • repository:存储相关,是gateway的特化,主要用来做本域的数据CRUD操作。
  • gateway:对外依赖的网关接口(Domain里的gateway)的实现。

在使用COLA的时候,请尽量按照组件规范约束去构建我们的应用。这样可以让我们的应用结构清晰、有章可循。如此这般,代码的可维护性和可理解性会得到极大的提升。

新扩展点设计

引入新概念

在讨论之前,我们先来明确一下在COLA2.0扩展设计中引入的新概念:业务、用例、场景。

  • 业务(Business):就是一个自负盈亏的财务主体,比如tmall、淘宝和零售通就是三个不同的业务。
  • 用例(Use Case):描述了用户和系统之间的互动,每个用例提供了一个或多个场景。比如,支付订单就是一个典型的用例。
  • 场景(Scenario):场景也被称为用例的实例(Instance),包括用例所有的可能情况(正常的和异常的)。比如对于“订单支付”这个用例,就有“可以使用花呗”,“支付宝余额不足”,“银行账户余额不足”等多个场景。

简单来说,就是一个业务是有多个用例组成的,一个用例是有多个场景组成的。用淘宝做一个简单示例,业务、用例和场景的关系如下:

新扩展点的实现

在COLA 2.0中,扩展的实现机制没有变化,主要变化就在于上文中引入的新概念。因为COLA 1.0的扩展设计思想来自于星环,所以当初的扩展粒度也是copy了星环的“业务身份”。COLA 1.0的扩展定位的方法如下图所示:

然而,在实际工作中,能像星环那样支撑多个业务的场景并不常见。更多是对不用用例,或是对同一个用例不同场景的差异化支持。比如“创建商品”和“更新商品”是两个用例,但是大部分的业务代码是可以复用的,只有一小部分需要差异化处理。


12下一页

鲜花

握手

雷人

路过

鸡蛋

相关阅读

资讯分类

推荐图文

文章排行

Powered by www.dastanona.com Copyright © 2013-2021 大奖18dj18vip社区 小黑屋|手机版|Archiver|地图|联系站长|腾讯云代金券|搜搜影视|seo优化服务|大奖18dj18vip
广告服务/项目合作/会员购买:QQ 侵权举报邮箱: kefu-sosoba@qq.com  大奖18dj18vip建站时间:创建于2013年07月23日
免责声明:大奖18dj18vip所有的内容均来自互联网以及第三方作者自由发布,版权归原作者版权所有,大奖18dj18vip不承担任何的法律责任,若有侵权请来信告知,我们立即删除!

GMT+8, 2021-1-20 07:48 , Processed in 0.025064 second(s), 8 queries , MemCached On.

返回顶部