虽然每天的工作都是CURD.还是使用着传统的三层架构.使用着.net Framework,但是这并不能影响我学习DDD和.net core. 总是希望软件在应对复杂多变的场景时能够游刃有余,在解决问题时能够多一种选择. 很早就有关注大神dax.net的NLayerApp系列博文https://www.cnblogs.com/daxnet/category/304141.html 近期入坑.net core,看了进击的辣条的文章Asp.Net Core微服务初体验,很有收获,感谢感谢. 抽时间读了

我们使用领域驱动设计(英文缩写为DDD)的方法来设计引擎,在引擎开发的过程中,领域模型会不断地演化. 本文介绍本系列使用的领域驱动设计思想的相关概念和知识点,给出了相关的资料. 上一篇博文 从0开发3D引擎(七):学习Reason语言 下一篇博文 从0开发3D引擎(八):准备"搭建引擎雏形" 概览 下面的资料粗略地介绍了DDD的相关知识点: 领域驱动设计学习输出 领域驱动设计(DDD)部分核心概念的个人理解 系统学习资料 相关资料为: DDD理论学习系列 为什么用DDD 参考领域驱动设

阅读目录 前言 明确业务细节 建模 实现 结语 一.前言 上一篇我们已经确立的购买上下文和销售上下文的交互方式,传送门在此:http://www.cnblogs.com/Zachary-Fan/p/DDD_6.html,本篇我们来实现售价上下文的具体细节. 二.明确业务细节 电商市场越来越成熟,竞争也越来越激烈,影响客户流量的关键因素之一就是价格,运营的主要打法之一也是价格,所以是商品价格是一个在电商中很重要的一环.正因为如此也让促销演变的越来越复杂,那么如何在编码上花点心思来尽可能的降低业务的

阅读目录 前言 如何在一个项目中实现多个上下文的业务 售价上下文与购买上下文的集成 结语 一.前言 前几篇已经实现了一个最简单的购买过程,这次开始往这个过程中增加一些东西.比如促销.会员价等,在我们的第一篇文章(如何一步一步用DDD设计一个电商网站(一)—— 先理解核心概念)中规划的上下文映射图可以看到,这些都属于一个独立的上下文(售价上下文). 二.如何在一个项目中实现多个上下文的业务 一般情况下,为了更好的分而治之,把不同的上下文作为单独的service,然后通过rpc框架(如WCF)来对其

1. 引言 限界上下文可以拆分为两个词,限界和上下文. 限界:是指一个界限,具体的某一个范围. 上下文:个人理解就是语境. 比如我们常说的段子: "我想静静." 这个句子一般是想表达"我想静一静"的意思.但是我们却把它玩笑成"静静是谁?". 可见上下文语境很重要. 这个例子只是个开胃菜,我们接着往下看. 2. 案例分析 整个应用程序之内的一个概念性边界. 边界之内的每种领域术语.词组或句子--也即通用语言,都有确定的上下文含义. 边界之外,这些术

本文从战略层面街上DDD中关于限界上下文的相关知识,并以ECO系统为例子,介绍如何识别上下文.限界上下文(Bounded Context)定义了每个模型的应用范围,在每个Bounded Context中确保领域模型的一致性:上下文图(Context Map)表示各个系统之间关系的总体视图:通过持续集成(Continous Integration)确保多个限界上下文的模型统一. 限界上下文(Bounded Context) 限界上下文(Bounded Context)定义了每个模型的应用范围,在每

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

前言 哈喽大家好,DDD领域驱动设计系列又开始了,前天周二的那篇入门文章中,也收到了一定的效果(写小说的除外),同时我也是倍感鸭梨,怎么说呢,DDD领域驱动设计已经有十年历史了,甚至更久,但是包括我在内的一批技术人员还是对其不是很明白,这几天我也是日思夜想,怎样才能说的明白,怎样才能把这个高高在上的思想落在实践上,可惜的是国内栗子比较少,国外文章比较少,只能硬啃了,所以更需要大家一起来讨论,这里要说一下,是一起讨论推动,而不是内心去拒绝,而一直和多层架构做对比,这样不仅不利于学习,也无法带动我的

最重要的一句话 DDD的所有有相关理论中,只有一句是至关重要的,但是也是最容易被忽略和最难做到的,抛弃传统的设计方式(思路)的思想,这句话起了决定性的作用,但是99%的人都忽略了或者在开始无法正视或理解. 为什么说这句话是最重要的一句话,因为他是设计真正转变的出发点. 基于具体的语义环境 首先,DDD的重点在于领域这个东西,领域的确定必须要基于一定的环境的,简单理解就是 必须同时具备主谓宾,比如:小明关爱小花:对于这句话的理解其实存在歧义,如果没有具体的语义环境下可能有以下两种理解方式: 1).

上一篇文章我们主要讲了订单上下文的领域逻辑,在领域逻辑中完成了订单项的计算逻辑.订单的计算逻辑以及如何生成相应的实体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中,同时会根据订单

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

上图是一张普通地图,最刺眼的就是边界? 非常好奇地图绘制工程师是如何描绘如此弯曲多变的边界的?强制行政区域还是人群历史原因自然的人以群分? 我们再换个视角,对工程师或者架构师来说,微服务的边界如何划分呢? 基于DDD设计方法论中的概念 限界上下文 来划分微服务的边界: 背景 架构师小李正在团队推行DDD设计方法论,领域建模和系统建设过程中,很多岗位需要参加进来,比如产品经理,领域专家,项目经理,架构师,开发经理,测试经理.对同样的领域知识,不同的人可能有不同的认识,交流起来存在一定障碍. 假如你

什么是通用语言 通用语言, 最主要的目的就是减少交流中信息丢失, 在实际开发中, 可能关联很多人, 例如有业务层面的业务细节制定者.领域专家.产品经理.项目经理 .架构师.开发经理.测试经理等等, 即使确定了核心域, 但是对于同样的领域知识, 每个人也有自己的理解, 举个例子, 我们通常说的商品和货物,是不是其实就是一个东西 ? 在销售领域叫商品, 但是一旦进入物流领域就叫货物, 所以我们一说商品就知道这是在销售子域, 一旦说货物就知道这是在物流领域, 如果只用物品来进行交流可能就会丢失信息,因

前一篇文章我们介绍了如何将创建产品的领域逻辑与产品的持久化仓储通过上架产品的用例组织起来,完成了一个功能.在实际的项目中,多种前端的形态比如PC Web. 微信小程序.原生APP等要调用后端的功能,通常要将后端的功能包装成RESTFUL风格,这样前端就可以使用Http Get或Post方式调用后端的功能,所以这篇文章我们先来完成后端 的Asp.net Core WebApi,通过WebApi将上架产品的功能暴露出去. 实现上下产品接口: [Produces("application/json&q

1.创建Dealer.Domain 类库项目 2.创建实体和值对象 3.安装ef的包 4.创建上下文接口(IDealerContext)之所以要创建上下文接口,是为了可替换,在其他项目总使用接口,当需要替换的时候,直接修改配置文件就可以了. 特别的,每一个webapi项目都有一个配置文件,所以针对不同的webapi可以使用不同的上下文. 5.创建上下文接口的实现类 DealerEFCoreContext,代码如下: namespace Dealer.Domain { public class D

1 界限上下文概念的出现 当开发一个电子商务系统的时候,会给系统划分很多子域,销售子域是核心子域,此外还有物流子域,商品子域等支撑子域.在这些子域里面,一个商品product在销售子域和商品子域里面外面对它的关注内容是一样的,但是在物流子域就不一样了.在商品子域,我们会常常使用它的单价属性.名称属性等,但是在物流子域我们就不关心它的单价.名字了.它只是一个贴了运单号的包裹.之所以出现这种差异,就是环境发生了变化,在此我们引入界限上下文的概念. 2 界限上下文的使用 针对每一个子域都引入界限上下文

Conference业务简介 Conference是这样一个系统,它提供了一个在线创建会议以及预订会议座位的平台.这个系统的用户有两类: 1:客户,可以创建和管理会议. 2:会议座位预定者,可以预订会议座位. 具体的关键业务描述如下: 1.客户登陆系统,客户可以创建一个会议,并录入会议的基本信息,比如名称.时间段.地点,参会人数等. 2.客户定义某个会议的座位类型,可以定义多个,每个座位类型包含的信息有:名称.座位价格.座位数量 ,根据座位类型自动生成座位编号. 3.客户发布或取消发布某个会议,