逻辑架构

逻辑架构由三层模型（表示层、业务层、持久化层）构成

表示层

前端端使用 Web 作为表示层，提供用户与组织系统、任务系统、支付系统

业务层

服务器充当业务层的角色，为表示层的各个子系统提供相应的服务模块

持久化层

SQLite 提供了数据的持久化服务

框架目录设计与逻辑架构与ECB的关系

框架目录设计与逻辑架构

• 框架目录设计：框架目录是为了服务开发人员，而非限制开发人员。 框架本身并不关注业务，至少不受业务影响或制约。框架就是要从具体的业务功能中，分离出能覆盖所有业务的设计、实现与组成，并使得各业务功能从开发实现的角度，变得解耦合、可重组、易维护。 不同的架构方法论，会将架构分为不同视图，每个视图侧重某一个方面、领域的问题。
• 逻辑架构：其关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描述，逻辑架构更偏向我们日常所理解的“分层”，把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。

ECB

• Boundary 对象：表示参与者与系统之间进行的交互以及信息交流
• Controller 对象：一个用例具有的事件流的控制行为
  • Boundary 发生的用户事件消息，皆是 Controller 的方法。
  • 以下都是不正确的交互：
    • UI 有箭头指向模型
    • 模型有箭头指向控制器。或控制器有除创建之外的箭头指向界面
    • 无论安卓或web，控制器都设计为多用户，即控制器不包含状态变量
  • 不能考虑多线程，使用多线程更新界面。要使用回调函数（消息）机制完成异步操作。
• Entity 对象：表示数据库中存储的信息及相关行为
  • 从 Domain Model 获取属性
  • 如果模型之间存在关联，请将关系转化为合适的实现（关联属性）
  • 将 Controller 消息转化为方法

在本系统中，Boundary有三个部分：

• 客户端 Web 程序用户界面
• 服务端 Caddy 反向代理服务器

Controller 包含：

• 服务器框架目录设计中，controller 目录下定义了所有的相关内容，它们接收来自上述 Boundary 的命令，并编排 service 的执行
• 服务器框架目录设计中，service 目录下定义了部分相关内容，它们接收也会对来自 Boundary 的命令进行相应的编排

Entity 包含：

• 服务器框架目录设计中，model 目录下定义了所有服务器与 SQLite 相关的实体，承载系统数据

两者关系

ECB是框架目录设计与逻辑架构的一种具体方法。

框架目录设计

前端

[tbd]

后端

[tbd]