随笔分类 - DDD(领域驱动)
Domain-Driven Design,领域驱动设计
摘要:关于她 LindAgile是大叔在这两年里的新宠儿,它主推模块化,插件化,敏捷化,主要于LindAgile基础项目,LindAgile.Http项目,LindAgile.Modules项目和几个扩展模块项目组成,那几个扩展模块主要体现的AOP的特性,需要哪些模块,就在应用程序里注册哪些。 LindA
阅读全文
摘要:回到目录 理论闲话 之前在.netFramework平台用的好好的,可升级到.net core平台之后,由于不再需要二进制序列化,导致咱们的事件机制遇到了问题,之前大叔的事件一直是将处理程序序列化后进行存储的,处理存储的参数为事件源,一个事件源可以由多个处理程序订阅,当事件源被发布时,这些被序列化的
阅读全文
摘要:在进行列表排序时,有个“上移”和“下移”操作,这个一般在内存里完成,然后统一提交到数据库中,对于上移与下移的设计,大叔在LIND.DDD.DOMAIN里有一个ISortBehavor接口,主要是说,如果实体对象支持排序功能,可以实现这个接口,而在扩展库中,将有为本地结果集动态排序(上移和下移)的方法
阅读全文
摘要:回到目录 Lind.DDD.Utils.HttpHelper组件主要实现了对HTTP的各种操作,如Get,Post,Put和Delete,它属于最纯粹的操作,大叔把它封装的目的主要为了实现与API安全授权的统一,你不可能为每个请求都写一个“逻辑完全一样的加密规则”,这是违背DRY原则的,我们应该通过
阅读全文
摘要:回到目录 本文来自于实践中的不足 在最近开始过程中,遇到了一个问题,之前设计的工作单元UoW只支持Insert,Update,Delete三种操作,即开发人员可以将以上三种操作同时扔进工作单元,由工作单元UoW负责事件的处理,这种设计已经出现很多年了,大叔感觉也是不错,思路就是在工作单元里添加三个字
阅读全文
摘要:回到目录 让大叔兴奋的自动化注册 对于领域事件之前说过,在程序启动时订阅(注册)一些事件处理程序,然后在程序的具体位置去发布(触发)它,这是传统的pub/sub模式的体现,当然也没有什么问题,为了让它支持分布式的场景,我们引用了redis这种存储介质,这一切都早已集成到了Lind.DDD架构中,对些
阅读全文
摘要:回到目录 戏说当年 大叔原创的分布式数据集缓存在之前的企业级框架里介绍过,大家可以关注《我心中的核心组件(可插拔的AOP)~第二回 缓存拦截器》,而今天主要对Lind.DDD.Caching进行更全面的解决,设计思想和主要核心内容进行讲解。其实在很多缓存架构在业界有很多,向.net运行时里也有Cac
阅读全文
摘要:回到目录 闲话多说 领域事件大叔感觉是最不好讲的一篇文章,所以拖欠了很久,但最终还是在2015年年前(阴历)把这个知识点讲一下,事件这个东西早在C#1.0时代就有了,那时学起来也是一个费劲,什么是委托,哪个是事件,搞的大家是糊里糊涂,进入C#2.0时代后,大叔也买了一本书,对于delegate和ev
阅读全文
摘要:回到目录工作单元UoW我们几乎在任务一个像样的框架里都可以找到它的足迹,是的,对于大型系统来说,他是很重要的,保持数据一致性,维持事务状态这都是它要为系统实现的功能,而在不同的框架里,实现UoW的机制也是不同的,在Lind.DDD中,采用了一种共同注册,统一提交的方式来实现UoW!UoW结构图我们来...
阅读全文
摘要:回到目录Lind.DDD.Repositories.EF以下简称Repositories.EF,之所以把它从Lind.DDD中拿出来,完全出于可插拔的考虑,让大家都能休会到IoC的魅力,用到哪种方法持久化,就将那个DLL放到应用程序中,完全不需要把所有持久化方式耦合到一个项目里,这也是遵循了OCP的...
阅读全文
摘要:回到目录Lind.DDD.Domain位于Lind.DDD核心项目中,它主要面向领域实体而设计,由一个IEntity的标识接口,EntityBase基类和N个Entity实体类组成,其中IEntity主要用来标识,在仓储操作时,用它来表明操作的实体范围和约束;EntityBase定义了几个公用的属性...
阅读全文
摘要:回到目录Lind.DDD.ConfigConstants属于新添加的组件,用来帮助我们安全的进行配置消息的管理,我们在开发项目时,有个感觉,你的config配置项会越来越多,越来越难以阅读,随着你引用的组件增多,添加更多的配置项也难以避免,而我自己的Lind.DDD框架也是如此,今天加个日志,明天加...
阅读全文
摘要:回到目录Lind.DDD项目主要面向敏捷,快速开发,领域驱动等,对于它的分层也是能合并的合并,比之前大叔的框架分层更粗糙一些,或者说更大胆一些,在开发人员使用上,可能会感觉更方便了,更益使用了,这就是大叔开发Lind.DDD框架的目的,让一切变得更简单...Lind.DDD层主要是公用方法,组件,规...
阅读全文
摘要:大叔只做技术支持,大叔不会在任何群打广告,大家不要上当受骗!!! 回到占占推荐博客索引 最近觉得自己的框架过于复杂,在实现开发使用中有些不爽,自己的朋友们也经常和我说,框架太麻烦了,要引用的类库太多;之前架构之所以这样设计,完全出于对职责分离和代码附复用的考虑,主要参考了微软的DDD大作《N_Lay
阅读全文
摘要:回到目录在Poco实体中,一般只有属性没有方法,这在软件设计中称为贫血模型,而在DDD领域驱动设计中,比较提倡充血模型,即你的Poco实体中,即有属性,也有操作属性的方法,注意这里说的是操作属性的方法,你的具体业务方法不要写在这里!而在实际项目中,我们可以有这样的需求,一个注册用户业务,它有密码和确...
阅读全文
摘要:回到目录上一讲主要说了领域事件和领域总线,这并不是一个很容易理解的文章,所以本讲实例篇主要是为了补充上一讲的理论知识,本讲实例关注的是实际中的订单处理模块,我们知道,订单处理是电子商务的核心,往往在这里面,会有很多逻辑,在开发时,给我们带来了不少的难度,如何更好的分离关注点,是本讲的主题;本讲主要是...
阅读全文
摘要:回到目录在之前写的DDD~基础设施层文章中,提到了UnitOfWork,它里面有一些方法,但经过项目证明,不应该有Save和IsExplicitSubmit,而这个工作单元只起到了数据上下文统一的作用,如A和B对象需要在同一个上下文中工作,这时,我们可以引用工作单元的概念,而对于保存和提交操作,还是...
阅读全文
摘要:回到目录对于一个聚合来说,它可能会被附加很多事件,这里我们叫它领域事务,因为一个聚会我们可以把它理解成一个领域,一个业务。对于领域事件不清楚的同学可以看看我的这篇文章《DDD~领域事件与事件总线》,里面有详细的说明,今天主要说一下领域里的事务,即领域事件的数据处理和主逻辑里的数据处理在同一事务里完成。知识准备SQL2005环境使用TransactionScopeNoMsdtc事务,它是占占开发的,原理是将一批操作包裹到一个SqlConnection里,由开发者维护接连的关闭,这也是使用时要特别注意的地方,因为如果不关闭连接,SQL链接池会益出。SQL2008环境使用微软自己的分布式事务实现Tr
阅读全文
摘要:回到目录图在前目前项目中可能出现的三种Model模式,对于我们现在开发的一个项目,我觉得使用DDD的思想来设计模型比较清晰,使用DDD的思想把模型model分成了如下三种:下面是我微博中的截图:上面的图中把模型分成了ViewModel,它与页面相关,DomainModel,它与业务模块相关,Model,它与数据库相关,它是对数据表的一种映射,一般用XML来表示。文字说明在后下面我们来举个例子,用认识一下这三个模型:下面以用户业务为例,来讲一个这三种模型UserDomainModelpublic class UserDomainModel { [Required] ...
阅读全文
摘要:回到目录谈谈它终于有些眉目了,搜刮了很多牛人的资料,英文的,中文的,民国文的,终于小有成就了,同时也做了个DEMO,领域事件这东西好,但需要你明白它之后才会说好,而对于明白领域事件这件事来说,它的门槛有点高,居然花了我三天的时间才把它搞定,嗨!占占给它的定义领域事件:Domain Event,是针对某个业务来说的,或者说针对某个聚合的业务来说的,例如订单生成这种业务,它可以同时对应一种事件,比如叫做OrderGeneratorEvent,而你的零散业务可能随时会变,加一些业务,减一些业务,而对于订单生成这个事件来说,它是唯一不变的,而我们需要把这些由产生订单而发生变化的事情拿出来,而拿出来的这
阅读全文