上一节我们讲解了常用的事务,也提及了Saga,这是在分布式环境下被经常使用的一种处理复杂业务和分布式事务的设计模式.本章我们的主要目标是编写一个简单版本的Saga处理器,不同于Seata框架中那种可独立部署的事务服务,我们所编写的Saga和业务集成在一起也不支持通过手画流程的方式实现,因为我们的目标是将Saga作为一种设计模式(不是框架)来使用,类似于您经常使用的"工厂"."策略"等,重点学习它的思想,在真实项目中使用肯定是需要根据需求做二次加工的.而且,简单版本的…
1. 背景 参考<DDD领域驱动设计-案例需求文档>,本文将构建实体,聚合根详述领域驱动中的建模设计.构建实体,聚合根的一些原则或方法,将在后续文章中说明. 2. 建模设计 2.1. 实体建模 参考售后补偿需求文档,对售后补偿业务做领域建模.现规划如下: 2.1.1. 补偿单聚合跟 补偿单聚合根主要是针对业务中,用户通过不同的场景创建补偿单的过程.如售后管理人员,客服人员通过后端管理系统发起补偿申请,电商用户通过app发起售后补偿申请.补偿单聚合根具有申请,修改状态,修改补偿信息等行为,整个过…
领域驱动和MVVM应用于UWP开发的一些思考 0x00 起因 有段时间没写博客了,其实最近本来是根据梳理的MSDN上的资料(UWP开发目录整理)有条不紊的进行UWP学习的.学习中有了心得体会或遇到了问题就写一篇博客记录一下,方便后面查询.不过前几天在园子里逛看了几篇领域驱动的文章,突然发现领域驱动设计的有些地方对我有了很大的提示.在之前用WPF做桌面开发时,使用MVVM可以把View和Model很好的解耦,但在处理数据持久化的时候并没有找到一种特别好的方式.我之前的做法是把ADO封装了一层SQL…
本博文将一步步揭秘京东等大型网站的领域驱动模型,致力于让读者完全掌握这种网络架构中的“高富帅”. 一.预备知识: 1.接口: python中并没有类似java等其它语言中的接口类型,但是python中有抽象类和抽象方法.如果一个抽象类有抽象方法,那么继承它的子类必须实现抽象类的所有方法,因此,我们基于python的抽象类和抽象方法实现接口功能. 示例代码: from abc import ABCMeta from abc import abstractmethod #导入抽象方法 class F…
上一篇:<IDDD 实现领域驱动设计-SOA.REST 和六边形架构> 阅读目录: CQRS-命令查询职责分离 EDA-事件驱动架构 Domin Event-领域事件 Long-Running Process(Saga)-长时处理过程 Event Sourcing-事件溯源 CQRS Journey-微软示例项目 ENode-netfocus 实践项目 存在即是理由,每一种架构的产生都会有一种特定的场景,或者解决某一种实际应用问题,经验的累积促成了某一种架构的产生. 1. CQRS-命令查询职…
从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个…
最近在做电商业务中,有关商品业务改版的一些东西,后端的架构设计采用现在很流行的微服务,有关微服务的简单概念: 微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成.系统中的各个微服务可被独立部署,各个微服务之间是松耦合的.每个微服务仅关注于完成一件任务并很好地完成该任务.在所有情况下,每个任务代表着一个小的业务能力. 关于改版的业务设计,还是想尝试 DDD 领域驱动设计,之前写的一些相关文章,都是直接进行战术设计,而非在战略设计基础上进行,所以最后可能会出现一些问题,所以这次的过程是…
设计文档模板: 系统背景和定位 业务需求描述 系统用例图 关键业务流程图 领域语言整理,主要是整理领域中的各种术语的定义,名词解释 领域划分(分析出子域.核心域.支撑域) 每个子域的领域模型设计(实体.值对象.聚合.领域事件,需要注意的是:领域模型是需要抽象的,要分析业务本质,而不是简单的直接对需求进行建模) 领域模型详细说明(如为什么这样设计的原因.模型内对象的关系.各种业务规则.数据一致性规则等) 领域服务.仓储.工厂设计 Saga流程设计 场景走查(讲述如何通过领域模型.领域服务.仓储.S…
概述 上一篇我们算是粗略的介绍了一下DDD,我们提到了实体.值类型和领域服务,也稍微讲到了DDD中的分层结构.但这只能算是一个很简单的介绍,并且我们在上篇的末尾还留下了一些问题,其中大家讨论比较多的,也是我本人之前有一些疑问的地方就是Repository.我之前觉得IRepository和三层里面的IDAL很像,为什么要整出这么个东西来:有人说用EF的话就不需要Repository了:IRepository是鸡肋等等. 我觉得这些问题都很好,我自己也觉得有问题,带着这些问题我们就来看一看Repo…
一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列可以说是刚接触领域驱动设计朋友的福音,本系列将结合领域驱动设计的思想来一步步构建一个网…