选择风格(Choosing a style)
咱们将依照Google在《使用架构攻略》中引荐的最佳实践和架构攻略来构建OrderNow的架构。
这些界说包括经过各层界说组件的一些Clean Architecture准则。
层次的界说(Definition of the layers)
在使用程序中，咱们将界说以下首要层次：
• 用户界面（UI）层
• 范畴层
• 数据层
UI层(UI Layer)
这一层组合了UI元素，Views视图（composable functions可组合函数），ViewModels和表明层的实用程序，例如格式使用器和动画。 规划这一层的留意事项包括：
• 关于状况处理，遵从规划准则中描绘的准则。
• 关于每个屏幕，将完成相应的ViewModel。
•viewmodels也将作为状况持有者，也便是状况管理器。
•导航逻辑将托付给视图，并将依靠于APP的状况。
•副作用应该报告给ViewModel。
•当配置发生变化时，Views模型应该坚持它们的状况。
•鼓励运用stateless Views(无状况视图)。
修改
范畴层(Domain Layer)
尽管这一层可所以可选的，但我主张包括它，以坚持与 Clean Architecture 规定的职责区分一致的规划。
这一层组合了被称为 UseCases 的组件，这些组件将管理事务逻辑和一切可由 ViewModels 重用的逻辑。
这一层还作为 UI 层(UI Layer)和数据层(Data Layer)之间的桥梁。
Models 类型的组件也归于这一层。
这些组件对表明层或范畴层运用的实体或数据结构进行建模。例如，在 OrderNow 中，“产品”和“类别”都表明模型或实体。
UseCases (用例)是一种规划形式，用于界说特定的事务逻辑或使用程序功用。它们用于封装特定的使用程序操作，通常涉及从数据层获取数据、处理数据以及将成果传递给UI层。在运用清洁架构时，UseCases 通常在范畴层中界说并由UI层调用。
修改
关于这一层的规划考虑包括：
• 一切在视图中重复的展现逻辑都能够放在UseCases (用例)中。
• 归于此层的组件可所以无状况的；它们是不需要临时耐久化的组件。
• UseCases (用例)履行的操作有必要是主线程安全的。
• UseCases 能够彼此通信，以协调用例操作。 • 每个 UseCases 负责一个且只有一个操作。
• 每个 UseCases 或许会运用一个或多个库房（Repositories）。
数据层（Data Layer）
这一层安排了名为库房（Repositories）的组件，它们协调和封装了与本地和远程数据源的集成逻辑。如其名称所示，它们遵从库房形式。 这一层的其他组件包括数据源（Datasources）、映射器（Mappers）和数据传输目标（DTOs）。
• 数据源（Datasource）：包括到外部或本地耐久化源的逻辑集成。
• 数据传输目标（DTO）：它是模型耐久化实体的结构。包括耐久性机制运用的界说。为了使其他层（UI和范畴）不承继这些界说，这些类型的实体经过映射器转换为使用程序域的模型。
映射器：它们将 DTO 转换为范畴层的模型实体。关于此层的规划，主张考虑以下事项：
• 此层可用作现实来历。
• 存储库履行的操作有必要是主安全的。
• 为每个首要实体类型界说一个存储库，例如，产品存储库、类别存储库。
修改
通用架构（General architecture）
不同集成层的通用图类似如下:
Architecture Layers架构层 ：
修改
关于其他层
补充架构首要层次的其他辅佐层将包括：
• Main（主层）：包括使用程序的根底构件，例如 MainActivity、Application 和 ApplicationState 等等。
• Common(通用层)：包括跨使用程序的构件，例如导航界说、用于其他层的实用工具和依靠管理器等等。
关于 PortsClean 架构的运用
主张在不同层的鸿沟之间包括端口，这种技术允许反转控制，解耦在每层鸿沟之间通信的组件。这种办法将为规划增加更好的可维护性和适应性。咱们的示例使用程序 （OrderNow） 将在Domain Layer 和Data layer之间增加端口。
修改
安排目录(Organizing directories)
在咱们的OrderNow示例中，为了简略起见，层次将经过单个模块中的目录以单体方法安排。 我将把是否在后续的项目中决议别离各层并为每个层献出一个模块的决议留给读者自行判断。
经过两个界说来进行目录安排：
• 在UI层，将运用按功用安排。
• 在Domain Layer(范畴层)和Data Layer(数据层)，将运用按组件安排。
修改
元素的命名和规范
关于组件命名，咱们将运用以下规矩：
运用后缀 只有在以下情况下才会在组件名中运用后缀：
• 包括包的名称没有推断出其类型。
• 需要强制组件代表的结构类型，例如，ProductRepository。
• 为了避免组件类型之间的混淆，例如，一个模型或许被命名为Category，其存储库名为 CategoryRepository。
后缀命名:
修改
命名包
使用程序包的名称有必要为小写，不能有分隔符，也不能有驼字。
修改
命名组件
关于组件类型UseCases的名称，表明用例中的操作(do, get, update, save, send, delete, add,履行、获取、更新、保存、发送、删除、增加)的操作被用作前缀。
修改
命名可组合函数
修改
关于UI组件，也便是可组合函数的界说，咱们将运用以下的命名规矩，这些规矩参阅了Google在架构攻略中的文档⁷：
Screen：用于表明整个屏幕的可组合函数的后缀。屏幕
UI：用于composables，这些composables将视图的状况（UI State）与组件的图形表明（UI Elements）结合在一起。用户界面
Elements：用于界说UI库组件（Buttons, Layouts, Checkbox, TextFields ,如按钮、布局、复选框、文本字段等）的composables的后缀，这些组件构成了视图。元素
Preview：用于预览视图（元素）的composables的前缀。Screen和UI composables也能够被组合预览，但由于对状况和其他变量的依靠性，它变得更加杂乱。
留意：
在构建使用程序时，尽管界说一切的组件类型很重要，但也或许存在例外情况，不需要界说一切的组件类型，能够省略一些。具体取决于使用程序中屏幕的杂乱程度，需要决议哪些组件类型适用，哪些不适用。
本章中，我想描绘在开端完成之前要遵从的架构界说。还澄清了用于安排使用程序项目的规矩。我有必要澄清，本章中给出的界说是主张性的。读者能够自界说或假定适合自己的约好和规矩，或者在完成中感到舒适的约好和规矩。在下一章中，咱们将开端完成OrderNow，首先要构建的是它的框架，即它的首要结构。
