架构整理 完美架构？

前言编码多年日常写代码有时会觉得项目现有架构碍手碍脚。经常在思考。如果我有机会重构重头再来我会如何设计呢思来想去可能我需要思考和掌握一个大而全的框架。开发的时候根据需求系统的复杂程度进行适当裁剪、融合。既不过度设计也不过于杂乱。一、先分大层表现层 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、表现层 Presentation1. 子层1View 视图子层包含WPF Window/Page、WinForm Form/UserControl、XAML界面、前台控件、资源样式职责纯界面渲染、捕获用户操作按钮点击、输入框、下拉选择、弹窗无任何逻辑所有操作转发给ViewModel仅持有对应ViewModel实例。禁止写校验、业务、数据库、接口逻辑。2. 子层2ViewModel 视图模型子层MVVM核心包含页面专属ViewModel、RelayCommand/DelegateCommand、页面状态容器Loading/成功/失败、页面交互事件转发职责接收View的用户操作调用Application层UseCase领域实体与UI模型互转维护页面状态流捕获业务异常转为界面提示不持有任何窗口控件引用。禁止编排多步骤业务流程、定义业务校验规则、直接调用仓储/数据库。3. 子层3UI Model 视图模型子层VO包含页面专用展示实体VO、页面入参、页面输出结果职责适配界面展示对Domain实体做裁剪、格式化、翻译数字状态转文字、拼接展示文本仅给View与ViewModel使用和领域实体解耦。禁止定义业务规则、持久化存储。4. 子层4SharedUI 界面公共子层包含全局弹窗工具、加载控件封装、UI通用扩展、页面基础基类、全局UI状态管理职责全项目页面复用的UI工具无业务关联所有ViewModel均可依赖。5.总结Presentation层内部依赖规则View 依赖 ViewModelViewModel 依赖 UI Model、SharedUIUI Model、SharedUI无内部依赖。2、Application 应用层顶层第二层业务集成层/UseCase层内部4个子分层从上至下依赖UseCase → DTO → Abstraction → SharedApplication1. 子层1UseCase 业务用例子层核心可理解成业务集成层包含单一完整业务用例类挂号、建档、预约转挂号、收费确认、扣减号源职责串联多仓储、多领域实体编排完整业务流程控制执行顺序、事务逻辑仅依赖Domain抽象仓库不碰数据库、UI一个UseCase只负责一件完整业务。禁止定义业务校验规则、操作数据库、处理界面弹窗。2. 子层2Application DTO 传输对象子层包含UseCase入参DTO、UseCase返回结果DTO职责隔离Presentation与Domain作为UI层和领域层的数据中转载体简化复杂领域实体只传递业务流程需要的字段。区分和UI VO不同DTO是业务流程中转VO是界面展示专用。3. 子层3Abstraction 应用抽象子层包含UseCase基类、业务结果统一返回包装器、事务抽象接口职责统一所有用例的基础模板封装统一返回格式、异常捕获模板复用通用流程骨架。4. 子层4SharedApplication 应用公共子层包含流程通用工具、分页包装、全局事务辅助、业务流水号生成器职责供所有UseCase复用的通用工具无业务定制规则。5.总结 Application层内部依赖规则UseCase 依赖 DTO、Abstraction、SharedApplication其余子层无互相依赖。3、Domain 领域层顶层第三层业务核心纯净无外部依赖内部4个子分层无上下依赖平级隔离互相可弱依赖无外部框架1. 子层1Entity 领域实体子层业务规则载体包含Patient患者、Schedule排班、Appointment预约、Registration挂号单、RegisterFee收费单等领域实体职责承载业务固有静态规则实体内部内置校验逻辑纯C# POCO类不依赖数据库、UI、第三方SDK全系统统一业务标准。禁止调用仓储、编排流程、持久化操作。2. 子层2Repository 仓储抽象接口子层包含IPatientRepository、IScheduleRepository、IAppointmentRepository 等纯接口职责只定义数据操作行为查询/新增/修改不提供任何实现Domain层仅依赖抽象完全隔离数据源。禁止写任何数据库操作、业务逻辑。3. 子层3Domain Exceptions 领域异常子层包含业务专属异常号源不足、重复建档、预约失效、身份证非法职责定义全系统统一业务错误UseCase、Entity校验失败时抛出上层统一捕获处理。4. 子层4Domain Shared 领域公共子层包含业务常量、业务枚举预约状态、支付状态、性别、领域基础工具身份证校验、金额计算、领域基础基类职责所有实体、仓储、用例共用的纯业务通用能力无外部依赖。5.总结Domain层内部依赖规则Entity、仓储接口、异常、公共工具平级可互相引用不依赖外层Application、Presentation、Infrastructure。4、Infrastructure 基础设施层顶层第四层数据对接层内部4个子分层依赖顺序Repository实现 → DataSource → Mapper → SharedInfra1. 子层1Repository Implement 仓储实现子层包含PatientRepository、ScheduleRepository 等实现类实现Domain定义的仓储抽象接口职责协调本地数据库、远程接口数据源组装数据查询/写入逻辑转换数据库/接口模型与Domain实体。禁止业务流程编排、业务规则校验。2. 子层2DataSource 数据源子层拆分本地远程细分两个更小模块- Local本地数据源EF实体、ADO模型、数据库PO、DAO数据访问类、本地缓存读写- Remote远程数据源后端API请求、HTTP封装、接口DTO、第三方服务调用医院支付中心职责纯原始数据读写只和数据库/网络交互无任何业务概念。3. 子层3Mapper 数据映射子层包含映射扩展类、转换工具PO ↔ Domain Entity、接口DTO ↔ Domain Entity职责隔离底层数据模型与纯净领域实体统一转换规则避免脏数据侵入Domain。4. 子层4SharedInfra 基础设施公共子层包含数据库连接封装、HTTP请求工具、日志、文件读写、缓存通用工具、第三方SDK封装职责所有数据源、仓储实现复用的底层工具无业务属性。5.总结 Infrastructure层内部依赖规则仓储实现依赖DataSource、Mapper、SharedInfra数据源、映射、公共工具平级无依赖。