机器学习的黄金标准

根据六边形架构的指导思想，在实际的应用分层中一般划分为四层，分别是：

• 用户接口层：负责用户展现相关的逻辑。
• 应用层：负责对一个用例进行流程编排(将接口用例分成若干个步骤，但是不负责每步的具体实施)。
• 领域层：负责实现核心的领域逻辑即业务逻辑(负责实现具体的业务逻辑)。
• 基础设施层：所有依赖的具体实现。

但是从应用架构的角度看，层级组织形式可以分为两种：

传统分层架构

如图9左侧，这种分层架构是Evic Evans在《Domain-Driven Design : Tackling Complexity in the Heart of Software》中提出的，其中用户接口层、应用层、领域层可直接依赖基础设施层，与图3的传统架构并无本质区别，因为所有层都直接依赖了基础设施层。这种方式需要强制开发同学将所有的依赖进行下沉，随着时间的推移这种规范非常容易被打破。

 

4 脚手架生成

当模型搭建完毕并且校验通过后可以将模型生成脚手架，其代码结构是按照六边形架构的标准生成的，六边形架构也成为端口与适配器架构，该架构的思想是将内部核心的领域逻辑与外界依赖进行隔离，这里的依赖是指所有对其他微服务的依赖、http的依赖、数据库依赖、缓存依赖、消息中间件依赖等等，所有的这些依赖都通过适配器进行转换成应用可理解可识别的最小化信息。

在实际的项目中，每种依赖都要考虑各种异常情况并进行处理，而这些处理实际上并不数据领域逻辑，却耦合到了业务代码里，当这种依赖多了对系统的稳定性会产生很大的影响，传统的分层架构虽然也会让我们将自身的领域逻辑和依赖进行分离，在阿里巴巴规范手册中提到所有的依赖都应该放到Manager层，但是这种规范是非常容易被打破的。六边形架构从应用分层上让我们更容易去遵守这样的规范。


 

阿里文娱早期的项目分层也基本都采用这种架构形式。上面的分层并没有问题，但是这种分层架构采用的是包的形式进行的层与层的隔离，需要每一位开发同学理解并且自觉遵守以上规范，但是在实际工作中我们发现很多同学对Service层和Manager层的区别并不是特别的清楚，即使清楚的同学大部分也并没有完全遵守手册中的规范，这种现象导致Manager层除了沉底一些通用能力以外和Service层并没有什么本质区别。

在实际的业务代码中Service层和Manager层都充斥了大量的第三方依赖，对系统的稳定性有很大的影响。每依赖一个第三方服务都要各种异常问题，这些异常处理的代码往往会和业务代码混在一起，当这种代码多了以后会使代码的可读性非常差。

阿里文娱业务的复杂度提升很快，业务迭代速度也很快， Service层和Manager层代码量迅速膨胀，业务逻辑变得越来越复杂。在这种业务场景下，大文娱引入了领域驱动设计并设计了一套完整的领域驱动模型评估与演进的解决方案来辅助开发同学将领域驱动设计的思想真正的落地。

四 文娱领域驱动设计实践

领域驱动设计的关键在于识别业务的模型，而模型又是会随着业务的发展而演进的，对于新的业务来说能效平台提供了业务模型分析的功能，开发同学可以在能效平台设计并搭建自己的领域模型，搭建出来后能效平台可以评估领域模型设计的是否合理，如果模型设计合理则可以基于以上设计的模型符合领域模型规范的代码。对于已有应用，能效平台设计了一套领域注解并以SDK的形式提供出去：

• 第一步：开发同学按照领域设计的原则对业务代码进行分析并打上注解。
• 第二步：能效平台可自动扫描该项目并收集该项目中的领域模型。
• 第三步：模型收集后，开发同学可以在能效平台改进业务模型并重新按照领域模型的规范生成代码。

完整流程如下图所示：



 

（编辑：莆田站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!