传送阵:写在最后 一.创建一个能跑的起来的Web API项目 1.建一个空的 ASP.NET Web应用 (为什么不直接添加一个Web API项目呢,那样会有些多余的内容(如js.css.Areas等),项目首先就需要清理一次.这样一步步来也更易于理解API项目) 2.用NuGet引入Web API 这时我的packages <?xml version="1.0" encoding="utf-8"?> <packages> <packa…

参照<maven实战>在本地创建对应的基本项目helloworld,在本地完成后项目结构如下: 可以看到maven项目的骨架:src/main/java(javaz主代码)src/test/java(测试代码)src/main/resuources(非java资源文件)pom.xml maven相关执行命令 mvn clean compile -->mvn clean test -->mvn clean package -->mvn clean install 首先cmd切换…

从这篇文章开始,我们根据前面的DDD理论与DDD框架的约束,正式进入直销系统案例的开发. 本篇文章主要讲产品上下文中的领域层的主要实现,先简单讲下业务方面的需求:产品SPU与产品SKU,产品SPU主要是产品的名字和相关描述, 产品SKU包括产品SPU的多个规格,每个规格有不同的价格与PV值.从我们对DDD概念的理解,产品SPU与产品SKU属于同一个聚合,产品SPU是聚合根. 产品上下文主要实现产品的上架功能,为了实现上架功能,我们首先要实现产品上下文的领域POCO模型与领域逻辑, 我们将产品的P…

前一篇文章我们完成了产品上下文的领域层,我们已经有了关于产品方面的简单领域逻辑,我们接着来实现产品上下文关于仓储持久化与应用层的用例如何来协调 领域逻辑与仓储持久化. 首先大家需要明确的是,产品上下文的领域逻辑是系统的核心,它不应该依赖仓储,而仓储应该要依赖领域层,这样仓储才可以把领域逻辑执行完后,才可能将 领域对象持久化到数据库中,这一点与传统的架构有本质的区别. 一般我们会在解决方案中建立一个项目,这个项目就是包含了所有聚合的仓储实现,具体不同上下文的仓储实现,可以在这个项目下建立不同的文件…

上篇文章主要讲述了经销商上下文的需求与POCO对象,这篇文章主要讲述该界限上下文的仓储与领域逻辑的实现. 关于界限上下文与EF Core数据访问上下文参考产品上下文相应的实现,这里不再累述. 因为在经销商上下文中有两个聚合,一个是经销商聚合,一个是登录聚合,所以我们需要实现两个仓储接口: 1.经销商仓储接口定义: public interface IDealerRepository { void CreateDealer<T>(T dealer) where T : class, IAggre…

这两天比较忙,周末也在加班,所以更新的就慢了一点,不过没关系,今天我们就进行千呼万唤的系统开发框架的设计.不知道上篇关于架构设计的文章大家有没有阅读,如果阅读后相信一定对架构设计有了更近一部的理解,如果你没有阅读也希望大家能好好阅读一下!其实说白了,架构是为了应对软件系统复杂度而提出的一个解决方案,架构设计的最终目的也就是为了让复杂的问题简单化!今天我们就结合架构设计的思想来进行我们的CMS实战项目的架构设计,接着再设计下开发框架吧.如果你有其他看法或者见解欢迎加入我们的实战项目交流群63732…

上篇给大家从零开始搭建了一个我们的ASP.NET Core CMS系统的开发框架,具体为什么那样设计我也已经在第十篇文章中进行了说明.不过文章发布后很多人都说了这样的分层不是很合理,什么数据库实体应该跟仓储放在一起形成领域对象,什么ViewModel应该放在应用层结构仓储层与UI层.其实我想说的是,这样都没问题,看你自己的理解了!我上篇文章已经说了,如果你愿意,完全可以把所有的层融合在一起,随意合并分离这个依你个人喜好. 我也是本着简单原则以及合适原则的思想来进行那样的分层结构,觉得这样层次更分…

连着两天更新叙述性的文章大家可别以为我转行了!哈哈!今天就继续讲讲我们的.NET Core实战项目之CMS系统的教程吧!这个系列教程拖得太久了,所以今天我就以菜单部分的增删改查为例来讲述下我的项目分层之间的协同工作吧!如果你觉得文中有任何不妥的地方还请留言或者加入DotNetCore实战千人交流群637326624跟大伙进行交流讨论吧! 本文已收录至<.NET Core实战项目之CMS 第一章 入门篇-开篇及总体规划> 作者:依乐祝 原文地址:https://www.cnblogs.com/y…

前面我们花了14篇的文章来给大家介绍经典DDD的概念.架构和实践.这篇文章我们来做一个完整的总结,另外生成一个Api接口文档. 一.DDD解决传统的开发的几大问题: 没有描述需求的设计模型:而是直接通过数据库表的方式体现,也就是需求与设计是脱节的. 编码的架构也没有与设计和需求对应起来. 业务逻辑与技术混在一起:业务逻辑可能直接调用的数据访问,这样把业务逻辑与数据访问的技术混在一起. 开发没有层次感和节奏感:系统没有一个统一的约束,开发人员没有一个统一的节奏,这主要体现在随意的编码. Bug 定…

上一篇文章我们讲了经典DDD架构对比传统三层架构的优势,以及经典DDD架构每一层的职责后,本篇文章将介绍基础结构层中支持DDD的轻量级框架的主要代码. 这里需要说明的是,DDD轻量级框架能够体现DDD的思想即可,没必要做得很重,你也可以根据理解,自己实现支持DDD的框架. 1.实体.聚合根与值对象的顶层体现 实体顶层定义: public interface IEntity { string Code { get; set; } Guid Id { get; set; } } Id是一个未来存储到…