目录 背景使用EntityFramework持久化聚合备注 背景返回目录 DDD中只有聚合根可以有仓储,仓储负责整个聚合持久化的相关生命周期,在不使用工作单元或POCO的情况下,我们可以让Order内部直接调用DAL操作OrderItem.我们也可以让Order跟踪所有OrderItem的状态,然后在OrderRepository内部操作OrderItem.如果我们采用了重量级的ORM工具,如:EntityFramework,事情会不会变得简单呢? 使用EntityFramework持久化聚合返…

背景 DDD中只有聚合根可以有仓储,仓储负责整个聚合持久化的相关生命周期,在不使用工作单元或POCO的情况下,我们可以让Order内部直接调用DAL操作OrderItem.我们也可以让Order跟踪所有OrderItem的状态,然后在OrderRepository内部操作OrderItem.如果我们采用了重量级的ORM工具,如:EntityFramework,事情会不会变得简单呢? 使用EntityFramework持久化聚合 关键思路:双主键. 示例聚合 这里以订单和订单项为例. Order管…

大家知道enode框架的架构是基于ddd+event sourcing的思想.我们持久化的不是聚合根的最新状态,而是聚合根产生的领域事件.最近我在思考如何实现一个基于文件的eventstore.目标有两个: 1.必须要高性能:2.支持聚合根事件的并发持久化,要确保单个聚合根实例不会保存版本号相同的事件: 事件持久化高性能 经过了一番调研,发现用文件存储事件非常合适.要确保高性能,我们可以顺序写文件(append),然后随机读文件.之所以要随机读文件是因为在当某些command由于操作同一个聚合根…

实体框架的持久化 当用EntityFramework持久化一个对象时,有两种情形:连接的和断开的 1.连接场景:使用同一个context上下文从数据库中查询和持久化实体时,查询和持久化实体期间,context不会被销毁 2.断开场景:实体的查询和保存提交使用不同的context上下文 上图所示,context1查询数据库中的实体然后被销毁,当实体变化时,应用程序使用context2来提交 这种情形是复杂的,因为新的context上下文不知道实体的变化,所以你不得不通知上下文. CRUD Oper…

前言: 前面的文章中IdentityServer4 配置内容都存储到内存中,本篇文章开始把配置信息存储到数据库中:本篇文章继续基于github的代码来实现配置数据持久化到MySQL中 一.基于EFCore持久化IdentityServer数据 1.数据库上下文(DbContext ) 在前面使用IDS4时,配置的一些基础:如Api资源.客户端等数据:以及在使用过程中授权后发放的token.授权.授权码等操作数据.如果持久化如何处理呢?IDS4已经提供了对应的方式 ConfigurationDbC…

一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列可以说是刚接触领域驱动设计朋友的福音,本系列将结合领域驱动设计的思想来一步步构建一个网…

前言 ENode是一个应用开发框架,为开发人员提供了一整套基于DDD+CQRS+ES+EDA架构风格的解决方案.ENode从发布1.0开始到现在的差不多两年时间,我几乎每周都在更新设计或实现代码.以至于从来没有一个稳定的版本可以提供给大家,非常惭愧.但我相信,随着时间的推移和我的努力的积累,ENode一定会越来越稳定和成熟的.我觉得我此刻很幸福,因为我有自己的兴趣且有机会在业余时间为了自己的兴趣而奋斗. ENode开源地址:https://github.com/tangxuehua/enode…

前言 今天是个开心的日子,又是周末,可以安心轻松的写写文章了.经过了大概3年的DDD理论积累,以及去年年初的第一个版本的event sourcing框架的开发以及项目实践经验,再通过今年上半年利用业余时间的设计与开发,我的enode框架终于可以和大家见面了. 自从Eric Evan提出DDD领域驱动设计以来已经过了很多年了,现在已经有很多人在学习或实践DDD.但是我发现目前能够支持DDD开发的框架还不多,至少在国内还不多.据我所知道的java和.net平台,国外比较有名的有:基于java平台的是…

转自:http://blog.csdn.net/derekjiang/article/details/9126185 英文原址:https://github.com/nathanmarz/storm/wiki/Trident-tutorial ---------------- Trident是在storm基础上,一个以realtime 计算为目标的高度抽象. 它在提供处理大吞吐量数据能力的同时,也提供了低延时分布式查询和有状态流式处理的能力. 如果你对Pig和Cascading这种高级批量处理工…

本片内容使用到ids4+ids4.Entityframework持久化表单,以及core的identity相关表的一并持久化,然后就是登录认证,认证使用email发送邮件的方式.所以这里涉及到四块内容,1.ids4的集成,2.ids4+core identity的相关默认表的持久化,以及在迁移库.表的过程中初始化相关数据(用户数据):3.登录认证 4.mailkit邮件发送(见上篇),框架是按照ddd搭建的,该篇内容只是ddd中的一个支撑域的东西(一个子域),用于统一认证和授权的,内容比较简单也…

领域驱动设计的概念 ​ 大家都知道软件开发不是一蹴而就的事情,我们不可能在不了解产品(或行业领域)的前提下进行软件开发,在开发前通常需要进行大量的业务知识梳理,然后才能到软件设计的层面,最后才是开发.而在业务知识梳理的过程中,必然会形成某个领域知识,根据领域知识来一步步驱动软件设计,就是领域驱动设计(DDD,Domain-Driven Design)的基本概念 . 为什么需要 DDD ​ 在业务初期,功能大都非常简单,普通的 CRUD 就基本能满足要求,此时系统是清晰的.但随着产品的不断迭代和演…

在微服务中使用领域事件   稍微回想一下计算机硬件的工作原理我们便不难发现,整个计算机的工作过程其实就是一个对事件的处理过程.当你点击鼠标.敲击键盘或者插上U盘时,计算机便以中断的形式处理各种外部事件.在软件开发领域,事件驱动架构(Event Driven Architecture,EDA)早已被开发者用于各种实践,典型的应用场景比如浏览器对用户输入的处理.消息机制以及SOA.最近几年重新进入开发者视野的响应式编程(Reactive Programming)更是将事件作为该编程模型中的一等公民.…

旅程3:订单和注册限界上下文 CQRS之旅的第一站 "寓言家和鳄鱼是一样的,只是名字不同" --约翰·劳森 描述: 订单和注册上下文有一部分职责在会议预订的过程中,在此上下文中,一个人(注册者)可以购买特定会议的座位.还可以为已购买的座位分配与会者的名称(这在第5章"准备发布V1版本"中进行了描述). 这是我们CQRS旅程的第一站,因此团队决定实现一个核心的.但自包含的系统部分--订单和注册.对与会者来说,注册过程必须尽可能地轻松.该流程必须确保业务客户能够预订到尽…

旅程4:扩展和增强订单和注册限界上下文 进一步探索订单和注册的有界上下文. "我明白,如果一个人想看些新鲜的东西,旅行并不是没有意义的."儒勒·凡尔纳,环游世界80天 对限界上下文的更改: 前一章详细描述了订单和注册限界上下文.本章描述了在CQRS之旅的第二阶段,团队在这个限界上下文中所做的一些更改. 本章的主题包括: 改进RegistrationProcessManager类中消息相关的工作方式.这说明了限界上下文中的聚合实例如何以复杂的方式进行交互. 实现一个记录定位器,使注册者能…

一.trident 的介绍 trident 的英文意思是三叉戟,在这里我的理解是因为之前我们通过之前的学习topology spout bolt 去处理数据是没有问题的,但trident 的对spout bolt 更高层次的一个抽象,其实现功能是一样的,只不过是trident做了更多的优化和封装.如果对处理的性能要求比较高,建议要采用spout bolt 来处理,反之则可以用trident trident 你可以这样理解,本身这个拓扑就是分散的,如果一个spout 可以有2个bolt,跟三叉戟比…

Martin Fowler在<企业应用架构模式>一书中写道: I found this(business logic) a curious term because there are few things that are less logical than business logic. 初略翻译过来可以理解为:业务逻辑是很没有逻辑的逻辑. 的确,很多时候软件的业务逻辑是无法通过推理而得到的,有时甚至是被臆想出来的.这样的结果使得原本已经很复杂的业务变得更加复杂而难以理解.而在具体编码实现…

前言 在这个万物互联的时代,物联网业务蓬勃发展,但也瞬息万变,对于开发人员来说,这是一种挑战,但也是一种“折磨”. 在业务发展初期,因为时间有限,我们一般会遵循“小步快跑,迭代试错”的原则进行业务开发,用通俗的话来说就是“no bb,先上了再说”,对于开发人员的具体实现,就是“脚本式”的开发方式,或者说是数据的 CURD,这样的开发方式,在项目早期没什么问题,但随着新业务的不断加入,业务迭代的频繁,我们会发现,现在的业务系统变得越来越冗杂,新加一个需求或者改一个业务,变得无比困难,因为业务实现彼…

写在前面 Martin Fowler在<企业应用架构模式>一书中写道: I found this(business logic) a curious term because there are few things that are less logical than business logic. 初略翻译过来可以理解为:业务逻辑是很没有逻辑的逻辑. 的确,很多时候软件的业务逻辑是无法通过推理而得到的,有时甚至是被臆想出来的.这样的结果使得原本已经很复杂的业务变得更加复杂而难以理解.而在具…

DDD总览 领域驱动设计(DDD)编码实践   目录 写在前面DDD总览实现业务的3种常见方式基于业务的分包领域模型的门面——应用服务业务的载体——聚合根实体 vs 值对象聚合根的家——资源库创生之柱——工厂必要的妥协——领域服务Command对象DDD中的读操作总结 写在前面 Martin Fowler在<企业应用架构模式>一书中写道: 1 I found this(business logic) a curious term because there are few things tha…

回顾 在上一篇博客[.Net设计模式系列]仓储(Repository)模式 ( 一 ) 中,通过各位兄台的评论中,可以看出在设计上还有很多的问题,在这里特别感谢 @横竖都溢 @ 浮云飞梦 2位兄台对博文中存在的问题给予指出,并提供出好的解决方案,同时也感谢其他园友的支持.欢迎各位园友对博文中出现的错误或者是设计误区给予指出,一方面防止“误人子弟”,另一方面则可以让大家共同成长. 对于上一篇博客,只是给大家提供了一种对于小型项目数据访问层的一种实现方式,通过Sql语句和传递参数来实现CRUD.并未…

在进行数据库添加.修改.删除时,为了保证事务的一致性,即操作要么全部成功,要么全部失败.例如银行A.B两个账户的转账业务.一方失败都会导致事务的不完整性,从而事务回滚.而工作单元模式可以跟踪事务,在操作完成时对事务进行统一提交. 具体实践 首先,讲解下设计思想:领域层通过相应的库实现泛型仓储接口来持久化聚合类,之后在抽象库中将对泛型仓储接口提供基础实现,并将对应的实体转化为SQl语句.这样领域层就不需要操作Sql语句即可完成CRUD操作,同时使用工作单元对事务进行统一提交. 1)定义仓储接口,包…

1 DDD是什么? DDD是领域驱动设计,是Eric Evans于2003年提出的,离现在有17年. 2 为什么需要DDD 当软件越来越复杂,实际开发中,大量的业务逻辑堆积在一个巨型类中的例子屡见不鲜,代码的复用性和扩展性无法得到保证.为了解决这样的问题,DDD提出了清晰的分层架构和领域对象的概念,让面向对象的分析和设计进入了一个新的阶段,对企业级软件开发起到了巨大的推动作用. 2.1 POP,OOP,DDD是如何解决问题 面向过程编程(POP),接触到需求第一步考虑把需求自顶向下分解成一个一个…

前言 ABP目前已经是很成熟的开发框架了,它提供了很多我们日常开发所必须的功能,并且很方便扩展,让我们能更专注于业务的开发.但是ABP官方并没有给我们实现工作流. 在.net core环境下的开源工作流引擎很少,其中WorkflowCore是一款轻量级工作流引擎,对于小型工作流和责任链类型的需求开发很适合,但只能通过后台编码或者json的方式定义工作流程,看了源码后觉得扩展性还是挺好的,至少能满足我的需求,于是选择对它下手. jsPlumb是一个开源的比较强大的绘图组件,这里不多介绍,我就是用它…

CQRS CQRS 的意思是"命令-查询责任隔离".我们分离了命令(写请求)和查询(读请求)之间的责任.写请求和读请求由不同的对象处理. 就是这样.我们可以进一步分割数据存储,使用单独的读写存储.一旦发生这种情况,可能会有许多读取存储,这些存储针对处理不同类型的查询或跨越多个边界上下文进行了优化.虽然经常讨论与 CQRS 相关的单独读写存储,但这并不是 CQRS 本身.CQRS 只是命令和查询的第一部分. 术语 Command 该命令是一个简单的数据结构,表示执行某些操作的请求. Co…

1 前置阅读 在阅读本文章之前,你可以先阅读: 什么是DDD DDD的实体.值对象.聚合根的基类和接口:设计与实现 2 什么是仓储? 仓储封装了基础设施来提供查询和持久化聚合操作. 它们集中提供常见的数据访问功能,从而提供更好的可维护性,并将用于访问数据库的基础结构或技术与领域模型层分离. 创建数据访问层和应用程序的业务逻辑层之间的抽象层. 实现仓储可让你的应用程序对数据存储介质的更改不敏感. 3 为什么仓储? 直接访问数据: 重复的代码 难以集中化与数据相关的策略(例如缓存) 编程错误的可能性…

Hadoop 社区推出了新一代分布式Key-value对象存储系统 Ozone,同时提供对象和文件访问的接口,从构架上解决了长久以来困扰HDFS的小文件问题.本文作为Ozone系列文章的第一篇,抛个砖,介绍Ozone的产生背景,主要架构和功能. 背景 HDFS是业界默认的大数据存储系统,在业界的大数据集群中有非常广泛的使用.HDFS集群有着很高的稳定性,得益于它较简单的构架,集群也很容易扩展.业界包含几千个数据节点,保存上百PB数据的集群也不鲜见. HDFS通过把文件系统元数据全部加载到Name…

EF - EntityFrameWork 中文名:实体框架(数据持久化框架) 1.使用EF查询(Linq to EF) 1.1使用标准查询运算符来查询 OumindBlogEntities db = new OumindBlogEntities(); IQueryable<BlogArticle> list = db.BlogArticles.Where(a => a.ACate==2); 1.2使用Linq to EF //1.EF默认使用延迟加载 //1.1 IQueryable&l…

本文用了EF,如果不适用EF的,请参考这篇文章,实现这些接口来自己定义存储等逻辑.http://www.cnblogs.com/stulzq/p/8144056.html IdentityServer具有良好的扩展性,其中一个可扩展点是用于IdentityServer所需数据的存储机制. 本快速入门介绍了如何配置IdentityServer以使用EntityFramework(EF)作为此数据的存储机制(而不是使用我们迄今为止使用的内存中实现). IdentityServer4.EntityFr…

背景 在之前的文章中<DDD:使用EntityFramework的话,如果只为聚合根设计仓储,其它实体如何处理?>,我介绍了如何映射聚合以保证其语义,当时的结论是:聚合内除了聚合根之外的实体必须使用多主键,否则删除操作(Order.OrderItems.Remove(1))只会将外键更新为 Null,最开始学习如何使用 EntityFramework 来映射聚合的时候,就纠结这个问题,当时汤雪华大哥就告诉了更新为 Null 就算删除了,当时感觉是接受了,不过没有内化,这篇文章也是为了内化这种思…

一.LINQ概述与查询语法 二.LINQ方法语法基础(重点) 三.LINQ聚合操作与元素操作(重点) 四.数据类型转换(重点) 一.LINQ概述与查询语法 1.LINQ(Language Integrated Query,语言集成查询)提供了一种跨数据源和数据格式查询的统一模型. 2.LINQ的组成: 1)LINQ To Objects:查询集合对象 2)LINQ enabled ADO.NET:查询数据库  LINQ To DataSet  LINQ To SQL  LINQ To En…