通过服务来协调领域对象,来添加产品用例. 1.要实现产品上下文的服务,首先新建一个项目,在Product解决方案文件夹下面新建一个项目,项目的名称为:Product.AppSrv. 2.这个项目首先引用Product.Domain项目,因为它操作领域对象,所以还要引用DDD.Repositories(为什么不取名Product.Repository呢,因为这个项目的初衷是放置所有的仓储实现,我们之前在里面定义了ProductRepositories文件夹). 因为它还要用到Util项目里面的东西…

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

从这篇文章开始,我们根据前面的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…

上一篇文章我们主要讲了订单上下文的领域逻辑,在领域逻辑中完成了订单项的计算逻辑.订单的计算逻辑以及如何生成相应的实体code,这篇文章我们通过 在应用服务中实现一个下单的用例,来将这些领域逻辑以及仓储整合起来,完成一个下单的用例. 先看下单用例主体的代码: public class CreateOrderUseCase:BaseAppSrv { private readonly IOrderRepository iorderrepository; private readonly IDealer…

前一篇文章主要讲了订单上下文的POCO模型,其中订单与订单项中有大量的值对象.这篇文章主要讲讲这些值对象以及订单项.订单相关的领域逻辑. 1.ProductSKUs值对象领域逻辑:ProductSKUs值对象用于订单项实体中,它的信息应该来源于产品上下文的ProductSKU实体. public partial class ProductSKUs { public ProductSKUs() { } public ProductSKUs CreateProductSKUs(ProductSKU…

在本系列前面的文章中,我们主要讨论了产品上下文与经销商上下文相关的实现,大家对DDD的方法与架构已经有了初步的了解. 但是在这两个界限上下文中,业务逻辑很简单,也没有用到更多的值对象的内容.从这篇文章开始,我们来讲讲订单界限上下文实现的内容, 里面的业务逻辑相对复杂一些,而且有大量值对象的引入来进行逻辑的处理. 订单上下文的需求主要是生成相应的订单项,每个订单项中有相关的订单产品和购买数量并生成订单项总额.订单项总PV,同时订单项总额 和订单项总PV会累加到订单总额和订单总PV中,同时会根据订单…

微服务到底怎么拆分和设计才算合理,拆多小才叫微服务?有没有好的方法来指导微服务和中台的设计呢? 深入DDD的核心知识体系与设计思想,带你掌握一套完整而系统的基于DDD的微服务拆分与设计方法,助力落地边界清晰.可持续演进的微服务架构. 欧创新,人保高级架构师,专注基于DDD的微服务设计和开发. DDD实战课,前往 找分享 订阅返现. 学后获得:DDD必知必会10大核心概念:掌握事件风暴与领域建模:上手中台业务建模与设计.…

要实现软件设计.软件开发在一个统一的思想.统一的节奏下进行,就应该有一个轻量级的框架对开发过程与代码编写做一定的约束. 虽然DDD是一个软件开发的方法,而不是具体的技术或框架,但拥有一个轻量级的框架仍然是必要的,为了开发一个支持DDD的框架,首先需要理解DDD的基本概念和 核心的组件. 一.什么是领域驱动设计(DDD) 首先要知道DDD是一种开发理念,核心是维护一个反应领域概念的模型(领域模型是软件最核心的部分,反应了软件的业务本质),然后通过大量模式来指导模型设计 与开发. DDD的一般过程是…

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