app功能界面架构图,app功能介绍主要从哪几个方面介绍

  

  每个软件项目都不一样,但不代表我们没有趋势可以选择。   

  

  大泥球当你不选择架构时,你最终会得到‘大泥球’架构。混乱的“大球”指的是从一个没有计划如何构建他们的解决方案的团队中出现的非结构化的意大利面条式代码库。   

  

     

  

  大泥球的名字来源于耦合和调用模式的非结构化网络,代表没有清晰架构的项目。   

  

  层次架构最简单也是最常见的一种架构风格就是层次架构。根据技术领域,代码被分成离散的层。这清楚地表明了代码的归属。   

  

     

  

  代码库通常被分解成多个层。   

  

  一个典型的规则是每个层都是封闭的,这意味着它只能被它旁边的层访问,这有助于防止耦合。每一层可以作为一个整体一起部署,也可以单独部署。通常,表示层(UI)和数据库将分别部署到代码的其余部分。   

  

  管道架构   

  

  流水线结构以两种类型的单元为中心;管道和过滤器:   

  

  过滤器是一个独立的无状态计算单元。他们应该专注于完成特定的任务。过滤器可以生成、测试、转换或使用数据。   

  

  它是管道过滤器之间的通信通道。它们是从过滤器构建管道的一种方式。   

  

  微内核架构(插件架构)   

  

  微体系结构基于构建核心系统的思想,核心系统包含系统实现其核心目的所需的最少功能。然后通过独立的插件提供附加功能。想想VS代码:基本的应用程序非常有限,但是通过添加插件,你可以让应用程序非常强大,为你和你的项目量身定制。   

  

  通常情况下,插件之间是相互隔离的,所以它们是相互分离的。他们也有独立的存储空间。插件可以是具有核心系统的单个单元的一部分,也可以单独部署。如果与插件的通信是通过某种标准化的消息形式(比如REST)完成的,那么就没有必要要求所有东西都用同一种语言编写。   

  

  基于服务的架构   

  

  在这种架构中,功能由基于域的服务来划分。该服务可以共享数据库和用户界面,但彼此独立运行。   

  

  服务可以彼此独立地部署。可以为需求更高的服务提供或复制更多的资源。还可能有一个API代理将请求从UI路由到正确的服务。   

  

  事件驱动架构   

  

  事件驱动系统对用户界面或内部事件做出“反应”。这个系统是由事件处理器构建的;小型独立计算单元。系统中的事件流可以通过两种不同的方式发生。   

  

  在代理拓扑结构下,没有对事件处理的集中控制。每个处理器可以广播自己的事件来触发另一个处理器形成事件链。不需要管理特定事件处理程序或执行步骤之间的连接。   

  

     

  

  中介拓扑下有一些中央控制。事件中介器控制调用哪些处理器以及事件进入系统的顺序。可能有多个事件中介以并行或分层的方式工作。   

  

  微服务架构   

  

  微系统由许多可独立部署的以域为中心的服务构成。“微”来源于每个服务应该只专注于完成一项任务。微服务通常使用REST之类的东西(可能通过API网关)进行通信,用不同的语言编写,有独立的存储。   

  

  服务通常是独立部署的。这是一种“云原生”架构,使用弹性来提供性能和可用性。   

  

  Clean Architecture   

  

  域:实体用例网关协议数据层:网关实现API(网络)数据库表示层:视图模型视图导航器场景用例   

哪几个方面介绍9.jpg">

  


  

  


  

  


  

  


  

实体实体封装了企业范围内的关键业务规则。实体可以是带有方法的对象,也可以是一组数据结构和函数。只要实体可以被企业中的许多不同应用程序使用,都没有关系。-清洁架构:软件结构和设计手工艺指南(Robert C. Martin)

  

实体是简单的数据结构:

  

struct Repo { var id = 0 var name = "" var fullname = "" var urlString = "" var starCount = 0 var folkCount = 0 var avatarURLString = ""}用例用例层中的软件包含特定于应用程序的业务规则。它封装并实现了系统的所有用例。这些用例协调了进出实体的数据流,并指示这些实体使用其关键业务规则来实现用例的目标。-清洁架构:软件结构和设计手工艺指南(Robert C. Martin)

  

UseCases是执行一项特定操作的协议:

  

protocol GettingRepos { var repoGateway: RepoGatewayType { get }}extension GettingRepos { func getRepos(_ dto: GetPageDto) -> Observable<PagingInfo<Repo>> { repoGateway.getRepos(dto) }}数据传输对象-DTODTO-在进程之间传送数据的对象,它还执行数据验证:

  

struct LoginDto: Dto { @Validated(.nonEmpty(message: "Please enter user name")) var username: String? @Validated(.nonEmpty(message: "Please enter password")) var password: String? var validatedProperties: { return <_username, _password> } init(username: String, password: String) { self.username = username self.password = password } init() { } static func validateUserName(_ username: String) -> Result<String, ValidationError> { LoginDto()._username.isValid(value: username) } static func validatePassword(_ password: String) -> Result<String, ValidationError> { LoginDto()._password.isValid(value: password) }}网关协议通常,网关只是另一个抽象,它将隐藏实际的实现,类似于外观模式。它可以是数据存储(存储库模式),API网关等。例如数据库网关将具有满足应用程序需求的方法。但是,请勿尝试在此类网关后面隐藏复杂的业务规则。对数据库的所有查询都应相对简单一些,例如CRUD操作,当然也可以接受一些过滤。-来源

  

protocol RepoGatewayType { func getRepos(_ dto: GetPageDto) -> Observable<PagingInfo<Repo>>}注意:为简单起见,我们将网关协议和实现放在同一文件中。实际上,网关协议应该在域层,实现应该在数据层。

  

资料层

  

数据层包含网关实现和一个或多个数据存储。网关负责协调来自不同数据存储的数据。数据存储可以是远程或本地(例如,持久数据库)。数据层仅取决于域层。

  


  

参考资料https://blog.devgenius.io/some-software-architecture-styles-fbb57f7716b9

  

https://www.nuomiphp.com/github/zh/5fdc441a99daa46c1242dceb.html

相关文章