如何在移动架构中应用软件理论？

如何在移动架构中应用软件理论？

在几段中，我们探索了您需要了解的所有内容，以便下次您设计应用程序时，您可以在风格上进行 世界级 .此外，我们分析了一个关键：决策者在公司中的作用。

决定开发一种移动架构类型的时刻 应用程序 这是整个项目中最具有决定性的一点。 它是选择一条可以引导你走向成功的道路，或者可以让你放弃一切，重新开始一份花费你几个月的工作。 .走一条或另一条路线不仅涉及团队的开发人员，还涉及公司的决策者。

当开发人员再也负担不起谷歌和苹果提供的移动架构时会发生什么？必须爬的时候怎么办 应用 数百万用户使用该架构？如果您必须考虑将由数十名开发人员开发的应用程序怎么办？在这篇文章中，我们将解开这些以及更多的问题，并讨论 软件 它们可以应用于移动架构。

谁是谁？：移动架构的简要回顾

iOS 和 Android 有一段有趣的移动架构历史：

• MVC ，最古老的之一，它的名字归功于 模型——视图——控制器 . 这种方法的问题在于，Apple 和 Google 实际上在该系统（模型 - 视图 - 控制器）方面遵循自己的模式，这最终并不是最佳选择。
• 然后 出现了一种新模式：MVVM。 这里的首字母缩略词回应 ** 模型-视图-视图模型** , 并表示其组成部分。在 iOS 上，这是一个进步，因为分发模式比以前的架构更好。在 Android 中，主要问题出现在应用程序复杂性增加时。这种架构的问题主要有两个。一是它专注于在屏幕上显示信息及其关系，而不是应用程序逻辑和提供它的数据所占据的位置。另一个大问题是它没有业务标准，对组件的组织和它们的关系结构不明确，随着规模需求的增长，这变得越来越复杂。
• 由于 MVVM 没有完成关闭，移动架构的新格局出现了： 蝰蛇 ( 视图、交互器、演示者、实体 y 路由器 ) .起初，它主要是 iOS 开发人员的工作，尽管它一点一点地进入了 Android。那些开发人员遇到了一种干净的架构方法，并从中看到了 将app的逻辑结构划分为不同的 责任层或层级 （我们稍后会深入探讨）。这样不存在依赖问题，增加了测试的可能性。但是，不完全推荐此模型，因为它并不为人所知，并且主要用于 iOS。因此，它不允许为 Android 和 iOS 实现通用架构。

应用于移动架构的软件理论

当我们回顾谷歌和苹果给我们的移动架构时，有必要 从一开始就重新思考我们处理项目的方式。至少要提前知道我们所有的选择 .

正如我们在开始时所说的那样，谷歌和苹果的移动架构（诚然，允许快速开发简单的应用程序）没有提供足够的扩展支持。因此，当您开始时，您必须考虑如何做一些任何人都可以在这些平台上使用的东西，并且将来可以扩展到数百万用户。

马可·斯卡比奥罗 ，redbee中的移动参考，告诉我们一些 启动项目时要在地图上掌握的关键理论 .其中之一是 滴滴涕 ( 领域驱动设计 ) . “这意味着首先你必须按照你的领域、产品或业务来组织事物，然后再按照结构来组织事物”，Marco 说。

即可以分为“用户域”、“注册域”、“搜索域”、“付费域”等结构元素。这样可以在需要时轻松定位。 “你可以让所有东西独立在不同的模块中，这些模块可以附加到任何 应用程序 .这给了你 能够与其他模块组装的灵活性 应用 ”，他补充说遵循这一理论原则的好处。

我们的开发人员带给我们的另一个理论是 **干净的 ** （我们谈论她的一些事情）。在这个（根据 Marco 的说法，任何好的架构都应该遵循），有一些重要的东西： 您必须能够组织各个部分，以便没有耦合，也就是说，所有部分都不会相互关联。

这 六边形结构 是一个分支 干净的， 在这里，构成应用程序的部件必须随时可更换。 “分为三层： 数据 ——这就是我获取信息的方式—— 应用程序 - 它具有应用程序的实际逻辑，以及 介绍 -这是关注界面以及如何向用户显示界面的层-”，我们的开发人员说。

尽管可能有一些变体，但绝大多数应用程序都遵循这个三元组。关键是它们是可替换的、轮廓清晰的 考虑尽早采用这一理论，以免为时已晚。

如何应用六边形架构？

一家拉丁美洲公司 零售 （redbee 客户端）正在寻求创建一个 应用程序 具有适用于最终用户和供应商的各种版本。 “它是关于 能够组装更专注于每个客户或具有不同功能的零售的微型产品 马克回忆道。

“ 建议组装模块，并且可以为每个客户提供他们想要的模块 以最低的技术成本和自由来进行营销报价 零售 最终”，我们的受访者补充道。从这个意义上说，他们选择了六边形架构，以便能够考虑业务部分之间的划分，这是一种灵活的架构，可以适应应用程序的发展并具有解耦的部分。

谁制定移动架构决策？

在决定遵循哪种移动理论和架构时，客户、项目负责人和开发团队都需要就这意味着什么达成一致。 如果您选择将时间和金钱投入到以后无法扩展的简单快速的应用程序上，这将意味着将来浪费时间和金钱。

“这个想法是 您自己的团队也会随着应用程序的发展而成长 ”，Marco 在谈到最大的公司组建开发团队所面临的挑战时反映 内部 坚硬的。否则，“团队本应拥有的有机增长与产品扩展到的有机增长之间会出现差距，”他补充道。

挑战在于考虑平台之外的架构 . “如果您提出适用于任何技术的基础架构，则更容易转向任何其他技术。如果两者（iOS 和 Android）都采用单一架构，您还可以更轻松地从一个架构迁移到另一个架构，”他最后说道。

然后，哪种架构更好？

尤其是在扩展应用程序时，我们的开发人员建议使用 MVVMSR（模型、视图、视图模型、服务、存储库） . “这是对结合了 DDD 和 Clean（六边形）的传统 MVVM 的修订版”，Marco 解释道。在此架构中，每个域都被描述并具有特定的职责，尽管它们之间可能存在依赖关系。此外，它们可以结合起来生成一个仅包含所需功能的点应用程序。

“这些域内部包含一个六边形架构，将其组件分为表示（视图、视图模型）、应用程序（模型、服务）和数据（存储库）”，我们的开发人员补充道。

这些段落几乎总结了我们在 redbee 工作的方法。我们不仅清楚有必要通过整合为客户提供额外价值的技术来支持我们的客户完成具有挑战性的项目，而且最重要的是， 我们确保我们希望客户的成长也强烈地体现在我们的团队中。

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明

本文链接：https://www.qanswer.top/37126/06421710