按照领域驱动设计的思路,我们搭建开发框架的解决方案如下:
*该解决方案正在改造过程中,会随着改造的过程逐步完善。
解决方案目录 | 对应领域设计层 | 说明 |
Infrastructure | 基础设施层 | 开发的底层类库 |
Core | 包括缓存、配置、日志、常用工具、数据访问等核心组件 | |
Core.Caching.Redis | Redis分布式缓存的实现 | |
Core.Data.Entity | EntityFramework的封装类库 | |
PlugIns | 主要针对外部产品的封装SDK,解决方案中暂缺 | |
Domain | 业务领域层 | 业务领域模型以及业务逻辑 |
Model | 业务领域实体 | |
Model.Mapping | 业务领域实体的数据库映射 | |
Repoistory | 业务领域仓储实现 | |
Repoistory.Interface | 业务领域仓储接口 | |
Service | 业务领域逻辑实现 | |
Service.Interface | 业务领域逻辑接口 | |
AppService | 应用服务层 | SOA方式,对上层提供服务 |
AppService | 对外提供的应用层服务 | |
AppService.Interface | 对外应用层服务的接口 | |
Presentation | 用户界面表现层 | 针对Windows/Web应用的组件和控件封装 |
Web.Library | Web网站类库和控件 | |
Web.Controls | Web控件 | |
Client | 客户端 | 客户端具体的实现 |
Areas | 客户端的Areas | |
Common | 公共区域 | |
DataWare | 数据仓库区域 | |
SampleWebApp | 样例网站 | |
StaticWebApp | 静态资源网站 | |
ConsoleApp | 控制台应用,主要是后台任务的调用。类似原先的Windows服务 | |
重点对Areas部分做下说明:我们将客户端整个应用按照业务模块进行划分,可以分为通用区域、门户区域、数据仓库区域、工作流和表单区域、CMS区域等等。为了少写些字,我在表格中只列出了门户和数据仓库区域。这样各个客户端应用在建立时,只需要引用相关区域即可,不一定把所有的区域都引用进来,这就是所谓的插件方式。以后仔细研究下ApplicationPart的做法,看看能否将Area修改为ApplicationPart。