如何正确地理解应用架构并开发(上)

简介: 如何正确地理解应用架构并开发(上)




许多同学或多或少都经历过这样的流程:

  1. 新同学刚来公司,学习了解团队的一些工程代码,并了解其中的代码风格
  2. 团队新接手了一些其他团队的项目,需要了解工程结构以及概念
  3. 如何定义工程项目的工程结构,包目录结构并达成团队共识

如果你有上述经历,并对工程应用之中的Module划分及其背后的意义理解上存在一些困扰, 那本文对你或许会有一些帮助。


理解代码从理解应用架构开始


应用架构

 混乱的应用架构


最近看了一些业务工程的代码,发现业务系统非常混乱,混乱主要体现在:

  1. 应用的层次结构混乱:不知道应用应该如何分层、应该包含哪些组件、组件之间的关系是什么
  2. 缺少规范的指导和约束:新加一段业务逻辑不知道放在什么地方(哪个类,哪个包)、应该起什么名字比较合适
  3. 每个工程的Module数量不一样,Module的命名和定义不一样,不同的Module之间的依赖关系混乱(延伸下就是:Module和Package的作用不清晰,不能很好的区分两者之间的区别


但有一个共同点就是都很复杂。导致复杂性的原因有很多,如果从架构的层面看,主要有两点:

  1. 架构设计过于复杂,层次太多能把人绕晕。
  2. 架构简单,ServiceImpl作为上帝类包揽一切,一杆捅到DAO(就简单场景而言,这种Transaction Script也还凑合,至少实现上手都快。


这种人为的复杂性导致系统越来越臃肿,越来越难维护,新来的同学,往往要捂着鼻子抠几天甚至几个月,才能理清系统和业务脉络,然后又一头扎进各种bug fix,业务修补的恶性循环中,暗无天日!

(Transaction Script地址:https://martinfowler.com/eaaCatalog/transactionScript.html


 有序的应用架构


一个没有架构的应用系统,就像一堆随意堆放、杂乱无章的玩具,只有熵值,没有熵减。而一个有良好架构的应用系统,有章法、有结构,一切都显得井井有条。

好的组织架构会遵循一定的架构模式,大部分的组织都会按职能和业务来设计自己的架构。如果你反其道而行之,硬要把销售、财务和技术人员放在一个部门,就会显得很奇怪。


对于应用架构而言,代码是其核心组成要素,结构就是这些代码该如何被组织,也就是要如何处理模块(Module)包(Package)类(Class)之间的关系。简而言之,应用架构就是要解决代码要如何被组织的问题。


 包和模块之间的区别


包和模块这两个概念是比较容易发生混淆的。比如在《实现领域驱动设计》中,作者就说: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。比如NBF-Falcon Framework基础类型的工程就包括如下3个Module:


<modules>
    <module>{应用Code}-api</module>
    <module>{应用Code}-service</module>
    <module>{应用Code}-start</module>
</modules>


的确,Module和Component这两个概念很相近,很容易造成混淆。比如,在StackOverflow上有一个提问,就是问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.「这两个概念类似,我通常认为“模块”比“组件”更大。组件是一个单独的部分,通常范围相对较小。」(StackOverflow地址:https://softwareengineering.stackexchange.com/questions/178927/is-there-a-difference-between-a-component-and-a-module?spm=ata.21736010.0.0.48807536xgth68

这个回答和我的直觉反应是一致的,即Module比Package要大。根据以上信息,我在此对Module和Package进行一下定义说明,在本文中,都会遵照如下的定义。- 模块(Module):和Maven中Module定义保持一致,简单理解就是Jar。- 包(Package):和UML中的定义类似,简单理解就是一个文件夹。
一个Moudle通常是由多个Package组成的,其关系如下图所示:


 典型的业务系统


典型的业务系统都需要:

  1. 接收request,响应response;
  2. 做业务逻辑处理,像校验参数,状态流转,业务计算等等;
  3. 和外部系统有联动,像数据库,微服务,搜索引擎等;

如何正确的组织这些业务代码,让他们处于自身该存在的位置,就是我们今天要聊的话题。


常见的工程结构(理论部分)


同样,好的应用架构,不管是六边形架构、洋葱圈架构、整洁架构等,都提倡以业务为核心,解耦外部依赖,分离业务复杂度和技术复杂度

简单理解下业务复杂度和技术复杂度的概念: 对于一个最简单的钱包扣钱的user case来说 业务复杂度:钱包扣钱时的规则(eg:不能扣成负值)就是业务复杂度 技术复杂度:钱包最终是如何存储的,是用mysql还是lindorm

应用架构的本质(核心),就是要从繁杂的业务系统中提炼出共性,找到解决业务问题的最佳共同模式,为开发人员提供统一的认知,治理混乱。帮助应用系统“从混乱到有序”,物流技术部的工程脚手架就是为此而生,其核心职责就是定义良好的应用结构,提供最佳实践。


 分层模式


分层是一种常见的根据系统中的角色(职责拆分)和组织代码单元的常规实践。常见的分层结构如下图所示:


 CQRS模式(命令和查询责任分离)


CQRS(Command Query Rsponsibility Segregation,命令查询分离)


其基本思想在于,任何一个对象的方法可以分为两大类:* 命令(Command):不返回任何结果(void),但会改变对象的状态。* 查询(Query):返回结果,但是不会改变对象的状态,对系统没有副作用。




 六边形架构


六边形架构是Alistair Cockburn在2005年提出,解决了传统的分层结构所带来的问题,实际上它也是一种分层架构,只不过不是上下,而是变成了内部和外部(如下图所示)。


六边形架构又称为端口-适配器架构,这个名字更容器理解。六边形架构将系统分为内部(内部六边形)和外部,内部代表了应用的业务逻辑,外部代表应用的驱动逻辑、基础设施或其他应用。


适配器分为两种类型(如下图所示),左侧代表 UI 的适配器被称为主动适配器(Driving Adapters),因为是它们发起了对应用的一些操作。而右侧表示和后端工具链接的适配器,被称为被动适配器(Driven Adapters),因为它们只会对主适配器的操作作出响应。

 洋葱圈架构


洋葱架构与六边形架构有着相同的思路,它们都通过编写适配器代码将应用核心从对基础设施的关注中解放出来,避免基础设施代码渗透到应用核心之中。这样应用使用的工具和传达机制都可以轻松地替换,可以一定程度地避免技术、工具或者供应商锁定。


不同的是洋葱架构还告诉我们,企业应用中存在着不止两个层次,它在业务逻辑中加入了一些在领域驱动设计的过程中被识别出来的层次(Application,Domain Service,Domain model,Infrastructure等)


另外,它还有着脱离真实基础设施和传达机制应用仍然可以运行的便利,这样可以使用 mock 代替它们方便测试。


在洋葱架构中,明确规定了依赖的方向:

  1. 外层依赖内层;
  2. 内层对外层无感知。



如何正确地理解应用架构并开发(中):https://developer.aliyun.com/article/1443482

目录
相关文章
|
9天前
|
机器学习/深度学习 API 语音技术
|
2天前
|
监控 持续交付 开发者
构建高效微服务架构:后端开发的新趋势
【4月更文挑战第18天】在数字化转型的浪潮中,微服务架构已成为企业提升系统灵活性、加速产品迭代的关键。此文深入探讨了构建高效微服务架构的实践方法,包括服务划分原则、容器化部署、持续集成/持续部署(CI/CD)流程以及监控与日志管理等关键技术点。通过分析具体案例,揭示了微服务在提高开发效率、降低维护成本及促进团队协作方面的显著优势。
|
4天前
|
人工智能 Serverless 数据处理
利用阿里云函数计算实现 Serverless 架构的应用
阿里云函数计算是事件驱动的Serverless服务,免服务器管理,自动扩展资源。它降低了基础设施成本,提高了开发效率,支持Web应用、数据处理、AI和定时任务等多种场景。通过实例展示了如何用Python实现图片压缩应用,通过OSS触发函数自动执行。阿里云函数计算在云计算时代助力企业实现快速迭代和高效运营。
3 0
|
5天前
|
监控 负载均衡 API
构建高性能微服务架构:后端开发的最佳实践
【4月更文挑战第14天】 在当今快速发展的软件开发领域,微服务架构已成为构建可扩展、灵活且容错的系统的首选方法。本文深入探讨了后端开发人员在设计和维护高性能微服务时需要遵循的一系列最佳实践。我们将从服务划分原则、容器化部署、API网关使用、负载均衡、服务监控与故障恢复等方面展开讨论,并结合实际案例分析如何优化微服务性能及可靠性。通过本文的阅读,读者将获得实施高效微服务架构的实用知识与策略。
|
7天前
|
运维 监控 自动驾驶
构建可扩展的应用程序:Apollo与微服务架构的完美结合
构建可扩展的应用程序:Apollo与微服务架构的完美结合
30 10
|
9天前
|
机器学习/深度学习 PyTorch API
|
9天前
|
机器学习/深度学习 语音技术 算法框架/工具
|
10天前
|
运维 Cloud Native 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【4月更文挑战第10天】 随着数字化转型的不断深入,企业对信息技术基础设施的要求日益提高。云原生架构作为一种新兴的设计理念和技术集合,以其灵活性、可扩展性和容错性,正在成为推动企业技术革新的关键力量。本文将探讨云原生技术的核心组件、实施策略以及面临的主要挑战,并分析如何通过采纳云原生架构来优化业务流程和提升服务效率。
|
12天前
|
API 数据库 开发者
构建高效可靠的微服务架构:后端开发的新范式
【4月更文挑战第8天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构面临着可扩展性、维护性和敏捷性的挑战。为了解决这些问题,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、实施策略及其带来的优势与挑战,为后端开发者提供一种全新视角,以实现更加灵活、高效和稳定的系统构建。
18 0
|
10天前
|
Kubernetes 安全 Java
构建高效微服务架构:从理论到实践
【4月更文挑战第9天】 在当今快速迭代与竞争激烈的软件市场中,微服务架构以其灵活性、可扩展性及容错性,成为众多企业转型的首选。本文将深入探讨如何从零开始构建一个高效的微服务系统,覆盖从概念理解、设计原则、技术选型到部署维护的各个阶段。通过实际案例分析与最佳实践分享,旨在为后端工程师提供一套全面的微服务构建指南,帮助读者在面对复杂系统设计时能够做出明智的决策,并提升系统的可靠性与维护效率。