按照领域驱动设计的思路,我们搭建开发框架的解决方案如下:
*该解决方案正在改造过程中,会随着改造的过程逐步完善。
解决方案目录 |
对应领域设计层 |
说明 |
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。