提炼问题域的意义 理解一个复杂问题域以便创建简单且有用的模型需要深入详尽的知识以及深刻的见解,这些只能通过与从内到外理解该领域的人协作得到.对模型的设计进行连续实验和探究正是DDD的能力所能实现的.只有通过协作以及共享对问题域的理解,你才能有效设计一个模型以应对业务的挑战,这样也才能具备足够的灵活性应对新出现的需求. 知识提炼与协作 复杂问题域会包含大量信息,其中一些将不适合于解决待处理的问题,并且只会分散你建模工作的实际重心. 知识提炼是从问题域中提炼出相关信息的技术,其目的是构建能满足业务用

前言 从13年接触DDD之后开始做应用架构已经整整四个年头. 四年里关于DDD的感触良多,慢慢有了一些心得. 关于DDD的介绍已经有很多的文章和书籍,这里我推荐三本最重要的书籍. <领域驱动设计-软件核心复杂性应对之道>(DDD) <实现领域驱动设计>(IDDD) <领域驱动设计模式,原理与实践>(PPPDDD) 具体的DDD介绍这三本书已经很清楚了,但是学完这些之后我认为DDD才刚刚开始. DDD给我更多的是一种设计启发,无论是里面的战术设计,还是战略设计都可以展开到

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

某大型互联网公司于2019年开始在XX中台财务域进行DDD实践.事后回顾,整体并没有达到预期的效果,个人也做了很多的反思和总结,形成此文. 1. 背景 为什么当时要实践DDD?其中的缘由比较复杂,可以从外部和内部两个视角来看. 首先,从外部也即整个BU的视角来看,最先开始实践DDD的是A域,并在该域诞生了一套在公司现有RPC框架之上的业务SPI框架(以下简称为[N框架]).相较于dubbo这样纯技术的服务框架,它有以下特点: 标榜serverless,自身提供了代码托管和运行容器,可以直接进行服

Entities are one of the core concepts of DDD (Domain Driven Design). Eric Evans describe it as "An object that is not fundamentally defined by its attributes, but rather by a thread of continuity and identity". So, entities have Id's and stored

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

业务和开发团队之间的协作是DDD必不可少的部分,并且它是处于开发阶段的产品获得成功的关键. 领域专家指的是那些从业务领域的政策和工作流程到棘手处和特性都具有深刻理解的人.能够为你的问题区域提供深刻见解的人.他们可能是对于你当前工作领域具有很强的领悟和理解的产品所有者.用户或其他任何人. 1.领域专家与业务相关人员的对比 DDD寻找到在你当前工作的领域中是主题专家的人很重要.而要找到领域专家,我们就要区分领域专家与业务相关人员. 问题空间会给出一组需求.输入和预期输出——这通常是你的业务相关人员提

1.通过通用语言达成共识 通用语言,已经强调过好多遍了,在DDD再怎么重视都不为过,后面可能还会讲. 知识提炼的输出以及共识的构建就是常见的通用语言(UL). 当与业务相关人员和主题专家进行建模时,每个人都应该有意识地始终应用富含领域专有术语的通用语言.这一语言必须现实制作,并在描述领域模型和问题域时使用.该语言还应该用于模型的代码实现,使用用作类名.属性和方法名称相同的术语和概念.正是这一语言使得业务和开发团队拥有了关于软件的有意义沟通. UL用于将模型的代码描述绑定到以业务能够理解的语言和图

名词解释 在DDD兴起的原因以及与微服务的关系中曾举了一个研究桃树的例子,如果要研究桃树,将桃树根据器官分成根.茎.叶.花.果实.种子,这每一种器官都可以认为是一个研究领域,而领域又有更加具体的细分,分成子域.核心域.通用域.支撑域等,下面回顾桃树这个例子 {{uploading-image-418761.png(uploading...)}} 看上面这张图 ,如果研究桃树是我们的业务,那么如何更加快速有效的研究桃树呢? 根据回忆,初中课本是这样研究的: 第一步: 确定研究的对象,即研究领域 ,

方式六:延迟对模型中概念的命名 对领域建模时命名很重要. 因为在不断的知识提炼过程中经常会发现已经被命名的概念与你最初理解的有出入,这时你当初的命名就会变成一个问题.其问题在于  最初选作名称的这个词所带来的“错误”联想  并且该联想还会限定你的思维方式. Gery Young(我也不认识是谁)建议,为你不确定的模型区域使用难以理解的词组成名称(例如可以用于问题域无关的 颜色 等).作为为模型区域或概念提供真实名称的替代方式,可以使用难以理解的词,直到你完全理解了一个关切问题所有的责任职责.行为

我们需要 DDD 的因素 – 微服务面试问题

我们需要 DDD 的因素 – 微服务面试问题

阅读目录 前言 场景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

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

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

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

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

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