腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

领域驱动设计DDD实战进阶

DDD第一波视频课程：请关注 “msshcj” 微信公众号 QQ群：309287205

专栏作者

73

文章

68005

阅读量

161

订阅数

DDD实战进阶第一波(九)：开发一般业务的大健康行业直销系统（实现经销商上下文仓储与领域逻辑）

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

2018-05-11

6540

领域驱动设计之聚合与聚合根实例二

这个实例主要说明一个论坛发帖与回复的场景。一般大家的理解是回复必须依赖与帖子，并且回复是没有单独存在的必要，并且帖子与回复通常具有一些不变性约束规则，比如发布一个回复，在帖子中同时增加一次回复次数；

2018-05-11

1.2K0

领域驱动设计之聚合与聚合根实例一

通过一个实例来说明如何划分聚合与聚合根场景：一个下订单的业务，一个订单必须有相应的客户信息，订单下有订单项，每个订单项必须有相应的产品信息，产品有分类的信息。 1.根据这个基本的需求，我们初步确定的

2018-05-11

2K0

领域驱动设计之聚合与聚合根

对实体与值对象等进行关联设计后，就应该进行聚合的划分以及聚合根的确定。首先我们需要明确为什么需要进行聚合的划分？原来我们的系统对领域划分的最小单位通常是模块，比如客户信息管理模块、雇员信息管理模块。但模块的划分对于设计来说，还是显得粒度太粗。一.聚合与聚合根 1.定义了对象之间清晰的关系和边界，并实现领域模型的内聚。我的理解是：一个聚合内的对象才具有强关联，对象的关联设计应该是针对一个聚合中的实体与实体或实体与值对象之间。（比如一个下订单的领域中，订单(实体)、订单项(实体)以及订单状态(值对象)应该

2018-05-11

2.5K0

领域驱动设计之实体、值对象、领域服务

数据库存储架构设计

建立领域模型的第一步就是需要识别出实体、值对象与领域服务。一.实体 1.实体是领域中需要唯一标识的领域概念。通常在业务中，需要唯一标识与区分的对象并需要持续对它进行跟踪，这样的对象我们认为是实体。这里的唯一标识通常指的是业务上的唯一标识，比如订单号、雇员工号等信息，而不是数据库中因为技术需要存储的自增int id或Guid列。 2.如果两个实体所有状态都一样，但如果标识不一样，就是两个不同实体。比如订单对象就应该是实体，就算两个订单的订单日期、订单总额等信息都一样，只要标识不一样，比如订单号，我们就认为它

2018-05-11

3.2K0

领域驱动设计案例之实现业务3

这一部分主要介绍如何实现下订单的业务，下订单的业务主要涉及到SalesOrder,OrderItem,CustomerInfo与ProductInfo几个领域对象 public partial class ProductInfo:ValueObject { public ProductInfo(Product product) { this.Id = base.Id; this.Name = product.Prod

2018-05-11

6380

领域驱动设计案例之业务实现2

这篇文章主要介绍如何创建产品信息。ModifyCount主要的作用是订单项成功后，相应的产品库存应该减少，库存减少由Product进行维护。 public partial class Product:AggreateRoot { private IRepository<Product> irepository; public Product(IRepository<Product> irepository) { this.ire

2018-05-11

5300

领域驱动设计案例之领域层实体与聚合根实现

数据库架构设计

在领域层中，可以实现实体与聚合根的业务逻辑，在实现业务逻辑之前，我们首先要确定实体和聚合根的一些基本行为，比如判断实体是否相等。关于领域对象的具体业务逻辑实现，因为涉及到要与数据库交互，所以等看完仓储的实现后，再实现领域对象的业务逻辑。 using System; using Order.Domain.Aggreate; namespace Order.Domain.Model { public abstract class Entity : IEntity { priva

2018-05-11

1.7K0

领域驱动设计-基本概念

数据库架构设计

我们略过需求的采集、直接进入需求分析与设计。领域驱动设计（DDD）是近10年流行、比较成熟、比较成功的软件分析与设计方法、理论。我们早期常见的软件开发方式是拿到产品需求后，直接考虑数据库中表应该如何设计，这种方式已经将分析、设计与业务需求脱节，而更多的是直接考虑应该如何实现了，这有点本末倒置。而DDD是从领域(问题域)为出发点进行的设计方法。这里先说一下领域驱动设计的概念：系统设计应该是一种以领域为核心的设计和开发理念。设计应该通过维护一个深度反应领域概念的模型，以及提供可行的经过实践检验的大量模式来应

2018-05-11

7520

领域驱动设计之仓储

在了解仓储之前，首先我们来看领域对象的生命周期。 1.首先通过调用领域对象的构造函数或工厂创建出对象，对象处于活动状态，这时对象可以进行相关业务逻辑处理。 2.对象如果需要进行持久化，则需要通过持久化

2018-05-11

1.2K0

领域驱动设计之关联设计

在找到实体与值对象后，我们就需要进行对象之间的关联设计。 1.关联尽量少，不要形成复杂的关系网。复杂的关系网不利于划分边界，理解与维护对象，同时对性能也有不利影响，通常关系只找出在整个业务生命周期都需要存在的关系。比如一个订单项需要关联到产品，但是仔细分析，一个订单项并不需要再整个业务生命周期都需要存在关系，订单项只需要在创建的那个时间点获得产品的价格与产品的名字而已，为了能够通过订单项看到产品的一些其他信息，可以在订单项上再保留一个产品的ID。 2.关联尽量保持单项，并且在建立关联时，考虑是否有一些关联的

2018-05-11

1.3K0

领域驱动设计-划分界限上下文

我们根据需求不要急于建立分析模型，而是应该先根据对需求的理解，将系统划分为多个界限上下文，每个界限上下文为独立解决业务的一部份的解决方案。比如一个电商平台，可以分为买家、卖家、商品、订单、退货等几个界限上下文。划分界限上下文是非常自然的事情。比如一个OA系统，可以分为部门与员工基础资料、费用管理、内部考试、学习中心、员工考勤、钉钉通知(各种业务事件发生时调用钉钉框架发送消息)等。界限上下文通常有三种类型，分别为核心域、支撑域、通用域。核心域：系统最核心并有复杂业务逻辑的业务界限上下文，比如电商平台的

2018-05-11

2.1K0

领域驱动设计之工厂

领域模型包含领域对象，也就是实体、值对象、领域服务。领域对象除了包含状态信息外，还包含必要的业务逻辑。为了能够使用这些领域对象，就需要实例化这些领域对象。实例化领域对象可以采用两种方式： 1.通过调用领域对象的构造函数对其进行实例化，比如Order order=new Order(); 2.通过调用领域对象的工厂方法对其进行实例化，比如Order order=Order.CreateFactory(); 一般情况下我们通过构造函数实例化就可以了，采用工厂方法对其进行实例化通常在以下两种场景中： 1.如果领

2018-05-11

1.2K0

领域驱动设计案例之领域层框架搭建

根据前面对领域驱动设计概念以及一些最佳实践的理解，领域模型是系统最核心的部分，我们还是采用前面销售订单的例子，这个案例系统的核心构建就从领域层开始。领域层框架搭建主要完成两个任务： 1.领域模型的建立

2018-05-11

9440

没有更多了

社区活动

腾讯技术创作狂欢月

“码”上创作 21 天，分 10000 元奖品池！

Python精品学习库

代码在线跑，知识轻松学

博客搬家 | 分享价值百万资源包

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

技术创作特训营·精选知识专栏

往期视频·千货材料·成员作品最新动态