架构整理 完美架构？

前言

编码多年，日常写代码有时会觉得项目现有架构碍手碍脚。

经常在思考。如果我有机会重构，重头再来，我会如何设计呢？

思来想去，可能我需要思考和掌握一个大而全的框架。开发的时候，根据需求系统的复杂程度进行适当裁剪、融合。既不过度设计，也不过于杂乱。

一、先分大层

表现层 （Presentation）、应用层（Application）、领域层（Domain）、基础设施层（Infrastucture）。

1、表现层 （Presentation）

管界面展示、用户点击。直接面向用户交互的最外层，负责处理界面展示、用户输入输出，如WinForm/WPF、Web前端页面，都属于这一层，仅做数据展示与交互响应，不包含核心业务逻辑。

2、应用层（Application）

管完整业务流程串联。作为表现层与领域层的调度中间层，负责协调业务流程流转，它只编排步骤，不实现具体的业务规则。管完整业务流程串联

3、领域层（Domain）

管业务实体、业务规则、数据行为抽象。整个架构的核心层，封装所有业务规则、实体对象、领域逻辑，比如工控场景下的设备状态计算、生产配方校验逻辑，所有核心业务规则都集中在这一层，不依赖其他层。

4、基础设施层（Infrastucture）

管数据库、网络、原始数据存取转换。为上层提供通用技术支撑的底层实现层，比如你熟悉的Oracle数据库访问、InfluxDB时序数据读写、PLC通讯组件、文件IO操作，所有底层技术细节都封装在这一层，为上层提供通用能力。

5、全局公共模块

不属于四大顶层层，所有层均可引用，无任何业务代码。

如：

1. 通用基础异常基类
2. 通用工具（日期、加密、正则、日志）
3. 通用扩展方法、基础数据类型包装
4. 依赖注入容器基础封装

二、各层再分层。

1、表现层 （Presentation）

1. 子层1：View 视图子层

包含：WPF Window/Page、WinForm Form/UserControl、XAML界面、前台控件、资源样式
职责：纯界面渲染、捕获用户操作（按钮点击、输入框、下拉选择、弹窗）；无任何逻辑，所有操作转发给ViewModel；仅持有对应ViewModel实例。
禁止：写校验、业务、数据库、接口逻辑。

2. 子层2：ViewModel 视图模型子层（MVVM核心）

包含：页面专属ViewModel、RelayCommand/DelegateCommand、页面状态容器（Loading/成功/失败）、页面交互事件转发
职责：接收View的用户操作；调用Application层UseCase；领域实体与UI模型互转；维护页面状态流；捕获业务异常转为界面提示；不持有任何窗口控件引用。
禁止：编排多步骤业务流程、定义业务校验规则、直接调用仓储/数据库。

3. 子层3：UI Model 视图模型子层（VO）

包含：页面专用展示实体VO、页面入参、页面输出结果
职责：适配界面展示，对Domain实体做裁剪、格式化、翻译（数字状态转文字、拼接展示文本）；仅给View与ViewModel使用，和领域实体解耦。
禁止：定义业务规则、持久化存储。

4. 子层4：SharedUI 界面公共子层

包含：全局弹窗工具、加载控件封装、UI通用扩展、页面基础基类、全局UI状态管理
职责：全项目页面复用的UI工具，无业务关联，所有ViewModel均可依赖。

5.总结Presentation层内部依赖规则

View 依赖 ViewModel；ViewModel 依赖 UI Model、SharedUI；UI Model、SharedUI无内部依赖。

2、Application 应用层

（顶层第二层，业务集成层/UseCase层）

内部4个子分层，从上至下依赖：UseCase → DTO → Abstraction → SharedApplication

1. 子层1：UseCase 业务用例子层（核心，可理解成业务集成层）

包含：单一完整业务用例类（挂号、建档、预约转挂号、收费确认、扣减号源）
职责：串联多仓储、多领域实体，编排完整业务流程；控制执行顺序、事务逻辑；仅依赖Domain抽象仓库，不碰数据库、UI；一个UseCase只负责一件完整业务。
禁止：定义业务校验规则、操作数据库、处理界面弹窗。

2. 子层2：Application DTO 传输对象子层

包含：UseCase入参DTO、UseCase返回结果DTO
职责：隔离Presentation与Domain，作为UI层和领域层的数据中转载体；简化复杂领域实体，只传递业务流程需要的字段。
区分：和UI VO不同，DTO是业务流程中转，VO是界面展示专用。

3. 子层3：Abstraction 应用抽象子层

包含：UseCase基类、业务结果统一返回包装器、事务抽象接口
职责：统一所有用例的基础模板，封装统一返回格式、异常捕获模板，复用通用流程骨架。

4. 子层4：SharedApplication 应用公共子层

包含：流程通用工具、分页包装、全局事务辅助、业务流水号生成器
职责：供所有UseCase复用的通用工具，无业务定制规则。

5.总结 Application层内部依赖规则

UseCase 依赖 DTO、Abstraction、SharedApplication；其余子层无互相依赖。

3、Domain 领域层（顶层第三层，业务核心，纯净无外部依赖）

内部4个子分层，无上下依赖，平级隔离（互相可弱依赖，无外部框架）

1. 子层1：Entity 领域实体子层（业务规则载体）

包含：Patient患者、Schedule排班、Appointment预约、Registration挂号单、RegisterFee收费单等领域实体
职责：承载业务固有静态规则，实体内部内置校验逻辑；纯C# POCO类，不依赖数据库、UI、第三方SDK；全系统统一业务标准。
禁止：调用仓储、编排流程、持久化操作。

2. 子层2：Repository 仓储抽象接口子层

包含：IPatientRepository、IScheduleRepository、IAppointmentRepository 等纯接口
职责：只定义数据操作行为（查询/新增/修改），不提供任何实现；Domain层仅依赖抽象，完全隔离数据源。
禁止：写任何数据库操作、业务逻辑。

3. 子层3：Domain Exceptions 领域异常子层

包含：业务专属异常（号源不足、重复建档、预约失效、身份证非法）
职责：定义全系统统一业务错误，UseCase、Entity校验失败时抛出，上层统一捕获处理。

4. 子层4：Domain Shared 领域公共子层

包含：业务常量、业务枚举（预约状态、支付状态、性别）、领域基础工具（身份证校验、金额计算）、领域基础基类
职责：所有实体、仓储、用例共用的纯业务通用能力，无外部依赖。

5.总结Domain层内部依赖规则

Entity、仓储接口、异常、公共工具平级，可互相引用，不依赖外层Application、Presentation、Infrastructure。

4、Infrastructure 基础设施层（顶层第四层，数据对接层）

内部4个子分层，依赖顺序：Repository实现 → DataSource → Mapper → SharedInfra

1. 子层1：Repository Implement 仓储实现子层

包含：PatientRepository、ScheduleRepository 等实现类，实现Domain定义的仓储抽象接口
职责：协调本地数据库、远程接口数据源；组装数据查询/写入逻辑；转换数据库/接口模型与Domain实体。
禁止：业务流程编排、业务规则校验。

2. 子层2：DataSource 数据源子层（拆分本地+远程）

细分两个更小模块：
- Local本地数据源：EF实体、ADO模型、数据库PO、DAO数据访问类、本地缓存读写
- Remote远程数据源：后端API请求、HTTP封装、接口DTO、第三方服务调用（医院支付中心）
职责：纯原始数据读写，只和数据库/网络交互，无任何业务概念。

3. 子层3：Mapper 数据映射子层

包含：映射扩展类、转换工具（PO ↔ Domain Entity、接口DTO ↔ Domain Entity）
职责：隔离底层数据模型与纯净领域实体，统一转换规则，避免脏数据侵入Domain。

4. 子层4：SharedInfra 基础设施公共子层

包含：数据库连接封装、HTTP请求工具、日志、文件读写、缓存通用工具、第三方SDK封装
职责：所有数据源、仓储实现复用的底层工具，无业务属性。

5.总结 Infrastructure层内部依赖规则

仓储实现依赖DataSource、Mapper、SharedInfra；数据源、映射、公共工具平级无依赖。