目录 MASA Framework - 整体设计思路 MASA Framework - EventBus设计 MASA Framework - MASA Framework - DDD设计(1) DDD 领域驱动设计是一个有关软件开发的方法论,它提出基于领域开发的开发模式,基于DDD理论,我们可以设计出高质量的软件模型. 它围绕业务概念构建领域模型来控制业务的复杂度,解决软件难以理解和演化的问题. 微服务 微服务是一种架构风格,通过进程间通讯.容错和故障隔离等方式,实现去中心化的服务治理. DD…

目录 MASA Framework - 整体设计思路 MASA Framework - EventBus设计 MASA Framework - MASA Framework - DDD设计(1) MASA Framework - MASA Framework - DDD设计(2) Clean Architecture 国内对于Clean Architecture的翻译很多,干净/整洁/清晰.但无论哪一种都说明了它简洁.清晰的特性. 早期它长这样 看到这张图的同学可能会对另外一张图有印象 洋葱架构…

目录 MASA Framework - 整体设计思路 MASA Framework - EventBus设计 概述 利用发布订阅模式来解耦不同架构层级,亦可用于解决隔离业务之间的交互 优点: 松耦合 横切关注点 可测试性 事件驱动 发布订阅模式 发布者通过调度中心将消息发送给订阅者.调度中心解决发布与订阅者之间的关系,保证消息可以送达订阅者手中. 发布者与订阅者互不相识,发布者只管向调度中心发布消息,而订阅者只关心自己订阅的消息类型 多订阅者保序执行 在常见的发布订阅模式中,的确很少见到类似的说…

源起 年初我们在找一款框架,希望它有如下几个特点: 学习成本低 只需要学.Net每年主推的技术栈和业务特性必须支持的中间件,给开发同学减负,只需要专注业务就好 个人见解:一款好用的框架应该是补充,而不是颠覆或过度创新 对扩展开放 可以按照业务需求任意调整依赖实现,而不被捆绑在一个架构思路上 功能强大却不限制架构,从单体到SOA再到微服务都可以适应 因为一个系统中总有复杂的也有简单的,最好能全面覆盖我们的业务场景 行业不限 既能支持传统行业的业务特殊性,又可以支持互联网行业的高并发特性 稳定性 有…

概述 事件总线是一种事件发布/订阅结构,通过发布订阅模式可以解耦不同架构层级,同样它也可以来解决业务之间的耦合,它有以下优点 松耦合 横切关注点 可测试性 事件驱动 发布订阅模式 通过下图我们可以快速了解发布订阅模式的本质 订阅者将自己关心的事件在调度中心进行注册 事件的发布者通过调度中心把事件发布出去 订阅者收到自己关心的事件变更并执行相对应业务 其中发布者无需知道订阅者是谁,订阅者彼此之间也互不认识,彼此之间互不干扰 事件总线类型 在Masa Framework中,将事件划分为 进程内事件…

领域驱动设计(DDD)的中心内容是如何将业务领域概念映射到软件工件中.大部分关于此主题的著作和文章都以 Eric Evans 的书<领域驱动设计>为基础,主要从概念和设计的角度探讨领域建模和设计情况.这些著作讨论实体.值对象.服务等 DDD 的主要内容,或者谈论通用语言.界定的上下文(Bounded Context)和防护层(Anti-Corruption Layer)这些的概念. 本文旨在从实践的角度探讨领域建模和设计,涉及如何着手处理领域模型并实际地实现它.我们将着眼于技术主管和架构师在实…

权限术语 Subject:用户,用户组 Action:对Object的操作,如增删改查等 Object:权限作用的对象,也可以理解为资源 Effect:规则的作用,如允许,拒绝 Condition:生效条件 Permission:允许(拒绝)用户(用户组)在条件允许下对对象(资源)的动作 Role:权限集合,权限数量>=1 RBAC RBAC (Role-Based Access Control,基于角色的访问控制),引入了 Role(角色)的概念,并且将权限与角色进行关联.用户通过扮演某种角色…

阅读目录 前言 场景1的思考 场景2的思考 避坑方式 实践 结语 一.前言 在上一篇中(如何一步一步用DDD设计一个电商网站(八)—— 会员价的集成),有一行注释的代码: public interface IRoleDiscountRelationRepository// : IRepository<RoleDiscountRelation> { RoleDiscountRelation Get(string roleId); } 其中涉及的到问题是关于值对象的持久化问题.是的,由于我们之前的…

阅读目录 前言 建模 实现 结语 一.前言 前面几篇已经实现了一个基本的购买+售价计算的过程,这次再让售价丰满一些,增加一个会员价的概念.会员价在现在的主流电商中,是一个不大常见的模式,其带来的问题是: 1.加大了运营的复杂度,会员价如何与促销结合,比如应在折前运用还是折后运用等. 2.如果是折前那么需要考虑满减类型促销的金额满足点门槛反而相对来说是提高了. 3.如果是折后那么享受了多重优惠,成本控制的时候需要考虑进去. 在我们这个练手的Demo中暂时决定让会员价在折后运用,并且仅在不满足满减促…

 阅读目录 前言 回顾 梳理 实现 结语 一.前言 之前的文章中已经涉及到了购买商品加入购物车,购物车内购物项的金额计算等功能.本篇准备把剩下的购物车的基本概念一次处理完. 二.回顾 在动手之前我对之前的购买上下文内对象做了一次回顾.先梳理一下已经在上下文内出现的领域对象,如图1所示: [图1] 在梳理的过程中,我把原来Cart.AddCartItem(string productId, int quantity, decimal price)重构为了Cart.AddCartItem(Produ…

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

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

阅读目录 前言 单元测试 纠正错误,重新出发 结语 一.前言 实际编码已经写了2篇了,在这过程中非常感谢有听到观点不同的声音,借着这个契机,今天这篇就把大家提出的建议一个个的过一遍,重新整理,重新出发,为了让接下去的DDD之路走的更好. 二.单元测试 蟋蟀兄在我的第三篇文章下面指出: 这点其实是我偷懒了,单元测试其实不单单在DDD中是一个很重要的一环,在我们崇尚敏捷,快速迭代的大背景下,有良好的单元测试模块可以保证快速迭代下的项目质量.有甚至可以使用测试先行的TDD模式. 单元测试的好处我就不多…

阅读目录 前言 怎么卖 领域服务的使用 回到现实 结语 一.前言 上篇中我们讲述了“把商品卖给用户”中的商品和用户的初步设计.现在把剩余的“卖”这个动作给做了.这里提醒一下,正常情况下,我们的每一步业务设计都需要和领域专家进行沟通,尽可能的符合通用语言的表述.这里的领域专家包括但不限于当前开发团队中对这块业务最了解的开发人员.系统实际的使用人等. 二.怎么卖 如果在没有结合当前上下文的情况下,用通用语言来表述,我们很容易把代码写成下面的这个样子(其中DomainRegistry只是一个简单的工厂…

一.前言 结合我们本次系列的第一篇博文中提到的上下文映射图(传送门:如何一步一步用DDD设计一个电商网站(一)—— 先理解核心概念),得知我们这个电商网站的核心域就是销售子域.因为电子商务是以信息网络技术为手段,以商品交换为中心的商务活动,一个好的核心域设计可以大大提升企业的竞争力和对市场变化的相应速度. 那么我们开始设计领域对象.对于设计领域对象的基本概念不了解的可以先阅读我的该系列第二篇文章(传送门:如何一步一步用DDD设计一个电商网站(二)—— 项目架构). 二.定义几个基类 我相信我们大…

阅读目录 前言 六边形架构 终于开始建项目了 DDD中的3个臭皮匠 CQRS(Command Query Responsibility Segregation) 结语 一.前言 上一篇我们讲了DDD的核心概念(附上链接),并且设计了我们的上下文映射图,那么接下来就准备开始立项了,本篇文章的部分知识点可能对一部分人来说比较基础,可以选择性的阅读. 在这之前我们平常用的最多的应该就是3层架构了,这里也不展开描述了,大家都是在3层的陪伴下一路走来的~ DDD所使用的传统分层架构是松散分层,也就是上层可…

最近在开发过程中,遇到了一个场景,甚是棘手,在这里分享一下.希望大家脑洞大开一起来想一下解决思路.鄙人也想了一个方案拿出来和大家一起探讨一下是否合理. 一.简单介绍一下涉及的对象概念 工作单元:维护变化的对象列表,在整块业务逻辑处理完全之后一次性写入到数据库中. 领域事件:领域对象本身发生某些变化时,发布的通知事件,告诉订阅者处理相关流程. 二.问题来了 我认为最合理的领域事件的触发点应该设计在领域对象内部,那么问题来了.当这个领域对象发生变化的上下文是一个复杂的业务场景,整个流程中会涉及到多个…

 阅读目录 前言 准备 实现 结语 一.前言 最近实在太忙,上周停更了一周.按流程一步一步走到现在,到达了整个下单流程的最后一公里——结算页的处理.从整个流程来看,这里需要用户填写的信息是最多的,那么在后端的设计中如何考虑到业务边界的划分,和相互之间的交互复杂度,又是我们需要考虑的地方.总体来说本篇讲述的内容在前几篇都有涉及,所以这次一次性处理的业务比较多,已经比较熟练的看官可以跳过本篇. 二.准备 主流的电商设计中结算页包含以下5个概念:选择收货地址.选择支付方式.选择快递.使用优惠券.使用余…

DDD设计一个电商网站(十一)-- 最后的准备    阅读目录 前言 准备 实现 结语 一.前言 最近实在太忙,上周停更了一周.按流程一步一步走到现在,到达了整个下单流程的最后一公里--结算页的处理.从整个流程来看,这里需要用户填写的信息是最多的,那么在后端的设计中如何考虑到业务边界的划分,和相互之间的交互复杂度,又是我们需要考虑的地方.总体来说本篇讲述的内容在前几篇都有涉及,所以这次一次性处理的业务比较多,已经比较熟练的看官可以跳过本篇. 二.准备 主流的电商设计中结算页包含以下5个概念:选择…

阅读目录 前言 解决数据一致性的方案 回到DDD 设计 实现 结语 一.前言 之前的十一篇把用户购买商品并提交订单整个流程上的中间环节都过了一遍.现在来到了这最后一个环节,提交订单.单从业务上看,这个动作的背后包含了多个业务操作,根据用户填写的订单信息生成订单.扣除使用的余额和积分.使用选择的礼券等等.其中涉及到多个上下文的操作,包括新引入的订单上下文,那么如何同时与多个上下文进行数据的写入操作是本篇主要想讨论的问题. 二.解决数据一致性的方案 分布式系统中的多个子系统之间的同时写入问题,也就是…

阅读目录 前言 回顾 本地的一致性 领域事件发布出现异常 订阅者处理出现异常 结语 一.前言 上篇中我们初步运用了领域事件,其中还有一些问题我们没有解决,所以实现是不健壮的,下面先来回顾一下. 二.回顾 先贴一下上篇中的遗留的问题: public Result Create(OrderRequest orderRequest) { if (!string.IsNullOrWhiteSpace(orderRequest.CouponId)) { var couponResult = DomainR…

本系列所有文章 如何一步一步用DDD设计一个电商网站(一)—— 先理解核心概念 如何一步一步用DDD设计一个电商网站(二)—— 项目架构 如何一步一步用DDD设计一个电商网站(三)—— 初涉核心域 如何一步一步用DDD设计一个电商网站(四)—— 把商品卖给用户 如何一步一步用DDD设计一个电商网站(五)—— 停下脚步,重新出发 如何一步一步用DDD设计一个电商网站(六)—— 给购物车加点料,集成售价上下文 如何一步一步用DDD设计一个电商网站(七)—— 实现售价上下文 如何一步一步用DDD设计一…

一.前言     DDD(领域驱动设计)的一些介绍网上资料很多,这里就不继续描述了.自己使用领域驱动设计摸滚打爬也有2年多的时间,出于对知识的总结和分享,也是对自我理解的一个公开检验,介于博客园这个平台也算是对DDD的推广尽了一份绵薄之力.一开始接触这个东西是在2014年,真的觉得像是发现了一片新大陆一般,对我整个程序开发视野有了新的理解,但是像[Vaughn Vernon]<实现领域驱动设计>里写的那样,景色虽好,可是自己很长一段时间内很混乱,理不清眼前的陌生世界,因为它与传统的观念完全不同…

本文介绍通过机器人框架设计器 (Bot framework composer)接近拖拉拽的方式设计一个聊天机器人,该聊天机器人的主要功能是发起http请求查询天气.当然,稍微变通下,可以用来查询几乎任何你想查询的内容,比如是否有新的日程,比如查询订单系统等等. 本文参照文档:https://docs.microsoft.com/zh-cn/composer/introduction 本文使用了一个模拟的天气查询api,该api提供北上广深的天气查询,其余城市返回404,具体见下图: 我们准备了一…

开发初衷 注册了博客园已经有几个月了,却从来都没有上来过,本人大概从2010年开始就开始做.NET 方向的开发. 这个是我在博客园发布的第一个帖子. 主要就是说说最近在写的一个ORM架构. 本人接触的ORM架构也有不少,没有一个是用着顺手的,要么就是配置起来特别吃力,要么就是使用起来不是很方便. 最终还是比较喜欢NHibernate这套架构,因为这套架构支持在Model表的实体类内部包含其他的表的实体类  也就是在使用的时候,连联表查询都可以省了 可以直接支持对象.对象的方式来进行查询数据,屡试…

First/FirstOrDefault: using (var ctx = new SchoolDBEntities()) { var student = (from s in ctx.Students where s.StudentName == "Student1" select s).FirstOrDefault<Student>(); } 对应的sql语句如下 ) [Extent1].[StudentID] AS [StudentID], [Extent1].[S…

看到网上讨论 DDD 的文章越来越多,咱也不能甘于人后啊,以下是我对 DDD 的个人理解,短小精悍,不喜忽喷. 也谈DDD(领域驱动设计) 解决什么问题 传统模式,产品评审结束,开发人员就凭经验拆分模块,设计数据结构,然后写业务逻辑实现功能.问题在于,不同人的经验.理念不一样,同样的产品需求,最终的技术实现也会不一样:就算是同一个人,可能不同时候接手同样的需求,也会出来不同的设计.究其原因,很多细节之处都是拍脑袋或按个人喜好,或以无所谓的心态处理了,得出的自然是各式各样的结果.往往这些结果是无法…

前言:又有差不多半个月没写点什么了,感觉这样很对不起自己似的.今天看到一篇博文里面写道:越是忙人越有时间写博客.呵呵,似乎有点道理,博主为了证明自己也是忙人,这不就来学习下DDD这么一个听上去高大上的东西.前面介绍了下MEF和AOP的相关知识,后面打算分享Automapper.仓储模式.WCF等东西的,可是每次准备动手写点什么的时候,就被要写的Demo难住了,比如仓储模式,使用过它的朋友应该知道,如果你的项目不是按照DDD的架构而引入仓储的设计,那么会让它变得很“鸡肋”,用不好就会十分痛苦,之前…

DDD领域驱动设计初探1 前言:又有差不多半个月没写点什么了,感觉这样很对不起自己似的.今天看到一篇博文里面写道:越是忙人越有时间写博客.呵呵,似乎有点道理,博主为了证明自己也是忙人,这不就来学习下DDD这么一个听上去高大上的东西.前面介绍了下MEF和AOP的相关知识,后面打算分享Automapper.仓储模式.WCF等东西的,可是每次准备动手写点什么的时候,就被要写的Demo难住了,比如仓储模式,使用过它的朋友应该知道,如果你的项目不是按照DDD的架构而引入仓储的设计,那么会让它变得很“鸡肋”…

前言:又有差不多半个月没写点什么了,感觉这样很对不起自己似的.今天看到一篇博文里面写道:越是忙人越有时间写博客.呵呵,似乎有点道理,博主为了证明自己也是忙人,这不就来学习下DDD这么一个听上去高大上的东西.前面介绍了下MEF和AOP的相关知识,后面打算分享Automapper.仓储模式.WCF等东西的,可是每次准备动手写点什么的时候,就被要写的Demo难住了,比如仓储模式,使用过它的朋友应该知道,如果你的项目不是按照DDD的架构而引入仓储的设计,那么会让它变得很“鸡肋”,用不好就会十分痛苦,之前…