应用架构的核心使命是什么？阿里高级技术专家这样说
|
洋葱架构与六边形架构有着相同的思路，它们都通过编写适配器代码将应用核心从对基础设施的关注中解放出来，避免基础设施代码渗透到应用核心之中。这样应用使用的工具和传达机制都可以轻松地替换，可以一定程度地避免技术、工具或者供应商锁定。不同的是洋葱架构还告诉我们，企业应用中存在着不止两个层次，它在业务逻辑中加入了一些在领域驱动设计的过程中被识别出来的层次(Application，Domain Service，Domain model，Infrastructure等)。 另外，它还有着脱离真实基础设施和传达机制应用仍然可以运行的便利，这样可以使用 mock 代替它们方便测试。
在洋葱架构中，明确规定了依赖的方向：
COLA应用架构 COLA架构是我团队自主研发的应用架构，目前已经开源。在COLA的设计中，我们充分汲取了经典架构的优秀思想。除此之外，我们补充了规范设计和扩展设计，并且使用Archetype的方式，将架构固化下来，以便可以快速的在开发中使用。 分层设计 COLA的分层是一种改良了的三层架构。主要是将传统的业务逻辑层拆分成应用层、领域层和基础实施层。如下图所示，左边是传统的分层架构，右边是COLA的分层架构。
其每一层的作用范围和含义如下： 1)展现层(Presentation Layer)：负责以Rest的格式接受Web请求，然后将请求路由给Application层执行，并返回视图模型(View Model)，其载体通常是DTO(Data Transfer Object); 2)应用层(Application Layer)：主要负责获取输入，组装上下文，做输入校验，调用领域层做业务处理，如果需要的话，发送消息通知。当然，层次是开放的，若有需要，应用层也可以直接访问基础实施层; 3)领域层(Domain Layer)：主要是封装了核心业务逻辑，并通过领域服务(Domain Service)和领域对象(Entities)的函数对外部提供业务逻辑的计算和处理; 4)基础实施层(Infrastructure Layer)：主要包含Tunnel(数据通道)、Config和Common。这里我们使用Tunnel这个概念来对所有的数据来源进行抽象，这些数据来源可以是数据库(MySQL，NoSql)、搜索引擎、文件系统、也可以是SOA服务等;Config负责应用的配置;Common是通用的工具类。 扩展设计 对于只有一个业务的简单场景，对扩展性的要求并不突出，这也是为什么扩展设计常被忽略的原因，因为我们大部分的系统都是从单一业务开始的。但是随着业务场景越来越复杂，代码里面开始出现大量的if-else逻辑。此时除了常规的策略模式以外，我们可以考虑在架构层面提供统一的扩展解决方案。 在扩展设计中，我们提炼出两个重要的概念，一个是业务身份，另一个是扩展点。 业务身份是指业务在系统唯一标识一个业务或者一个场景的标志。在具体实现中，我们使用BizCode来表示业务身份，其中BizCode采用类似Java包名命名空间的方式。例如，我们可以用“ali.tmall”表示阿里天猫业务，用“ali.tmall.car” 表示阿里天猫的汽车业务，而用"ali.tmall.car.aftermarket"代表这是阿里天猫的汽车业务的后市场场景。 每个业务或者场景都可以实现一个或多个扩展点(ExtensionPoint)，也就是说一个业务身份加上一个扩展点，可以唯一地确定一个扩展实现(Extension)。而这个业务身份和扩展点的组合，我们将其称之为扩展坐标(ExtensionCoordinate)，如下图所示。
这样，通过业务身份+扩展点，我们就可以从框架层面实现对不同租户，不同业务，不同场景的扩展定制了。整个阿里业务中台正是基于这个思想，实现的多业务支撑的。 规范设计 任何事物都是规则性和随机性的组合。规范的意义就在于我们可以将规则性的东西固化下来，尽量减少随心所欲带来的复杂度，一致性可以降低系统复杂度。从命名到架构皆是如此，而架构本身就是一种规范和约束，破坏这个约束，也就破坏了架构。 COLA制定了一些列的规范：包括组件(Module)结构、包(Package)结构、命名等。 比如对于组件，我们要求使用COLA的应用都应该遵循如下图所示的组件划分：
COLA架构总览 在架构思想上，COLA主张像六边形架构那样，使用端口-适配器去解耦技术细节;主张像洋葱圈架构那样，以领域为核心，并通过依赖倒置反转领域层的依赖方向。最终形成如下图所示的组件关系。
（编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
