DDD
K-Darker
1、每天读书;2、学习新的语言;3、战胜你的恐惧;4、升级你的技能;5、承认自己的缺点;6、向你佩服的人学习
展开
-
领域驱动战略设计实践-建立统一语言
统一语言是提炼领域知识的产出物,获得统一语言就是需求分析的过程,也是团队中各个角色就系统目标、范围与具体功能达成一致的过程。使用统一语言可以帮助我们将参与讨论的客户、领域专家与开发团队拉到同一个维度空间进行讨论,若没有达成这种一致性,那就是鸡同鸭讲,毫无沟通效率,相反还可能造成误解。因此,在沟通需求时,团队中的每个人都应使用统一语言进行交流。一旦确定了统一语言,无论是与领域专家的讨论,还是最终...原创 2019-03-24 13:38:11 · 1706 阅读 · 1 评论 -
DDD之挖掘通用语言实战
通用语言作用团队成员概念统一,理解一致,有文档落地。帮助产品快速理解用户需求 》帮助工程师快速理解业务需求 》帮助工程师落地能实现用户需求的代码。深入理解领域上下文是什么,能干什么,以及和其他领域上下文的边界。通用语言的统一:有上下文 有文档的三方(用户 产品 开发 测试)达成一致标准确认上下文边界也是确认不同系统之间边界通用语言的定义和表达1:说明了...原创 2019-07-20 18:15:46 · 589 阅读 · 0 评论 -
领域驱动设计 -- 聚合
聚合的定义聚合,字面意思就很简洁明了,是把领域对象聚合在一起,并维护领域对象之间的关系。我们来解释下这句话中出现的几个名词:名词解释领域对象实体,并且只有实体领域对象的关系实体之间的固定业务关系,主要是逻辑关系(如一对多)和聚合业务逻辑聚合根聚合的根,聚合业务的发起者,领域对象关系的起点。所以我们总结下聚合的定义:聚合根发起的,并维护多个实体间固定业...转载 2019-07-17 21:34:27 · 1000 阅读 · 0 评论 -
领域驱动设计 -- 值对象
值对象的定义简单来说,值对象是对事物的描述,更确切的说,就是对领域对象的描述。描述这个词很好理解,一般都是形容词,比如说美丽的女人,这里美丽就是对女人的外貌描述。也可以是多个形容词的组合,比如说美丽动人可爱的女人,这里的描述就是美丽、动人、可爱三个形容词的组合。对领域的描述也是如此,有简单的描述,也会有复杂形容词组成在一起的描述,简单的说,就是一个属性字段,复杂描述就是多个属性字段组成的VO...转载 2019-07-16 20:33:31 · 1245 阅读 · 1 评论 -
领域模型的图文表示法
领域模型的图文表示法领域模型定义实体、值对象、聚合、工厂、仓库、领域服务 6 种领域元素的定义,并且管理 6 种领域元素之间的内部关系和外部关系。注: 我们下面领域模型只涉及到 : 实体 值对象 聚合 领域能力 领域服务 不涉及工厂、仓库上面的领域模型从里面还是不能直接对应到我们的代码,我们在建立通用语言的时候没有细致到没有考虑到我们实体没有 考虑到我们值对象没有考虑需求的动作...原创 2019-07-23 18:49:41 · 2166 阅读 · 1 评论 -
领域驱动设计 -- 工厂
工厂的由来在平时工作中,如果领域对象的创建逻辑比较简单,那么通过构造器即可创建,如果领域对象的创建逻辑比较复杂的时候,构造器就无法胜任创建的工作了,DDD 中引入了一个新的领域概念来做这个事情:工厂。领域对象的创建逻辑复不复杂,其实很难判断,一般在 Java 语言,类的构造器参数大于 3 个的时候,再使用构造器创建就不太合适了,这时候我们会新建一个工厂,来创建 Java 类,同理,当领域对象的...转载 2019-07-18 18:42:31 · 803 阅读 · 0 评论 -
领域驱动设计 -- 实体
实体的定义我们在定义一个概念的时候,常常会说这个概念是由那些部分构成的,按照这个套路来说,实体是由属性和行为组成的,属性指的是实体本身的特质,行为指的实体本身的能力,实体能干什么。如果一个实体表示的业务概念较大,那么属性和能力就会较多,在描述这个实体是什么的时候,你需要把属性和能力都列举出来,沟通很费力费时。我们在给领域元素做定义的时候,最好不要采用举例子的方式来解释,也不要用一个复杂名词取...原创 2019-07-15 18:21:00 · 934 阅读 · 0 评论 -
领域驱动设计-- 模型
什么是模型从领域驱动的战略设计进入战术设计,简单说来,就是跨过系统视角的限界上下文边界进入它的内部,从分层架构的逻辑分层进入到每一层的内部。在思考内部的设计细节时,首先需要思考的问题就是:什么是模型(Model)?模型是从哪里来的,怎么得出来的。注:这里的模型不仅仅是我们数据库建模还是来看看 Eric Evans 对模型的阐述:为了创建真正能为用户活动所用的软件,开发团队必须运用一整套与...原创 2019-07-06 12:23:58 · 752 阅读 · 0 评论 -
领域驱动设计 -- 最快学习路径介绍
从战略入门这种方式相对比第一种方法,费时很多,需要很大的毅力坚持,但因为是在实践中不断成长的,最终是可以形成自己的方法论的。但耗时太慢长,我自己不断实践落地 DDD 近 5 年,才形成了自己一丢丢的方法论。接下来给大家提供一些总结的资料,供大家入门学习:实体、聚合、值对象、聚合、工厂、仓储、领域服务等领域模型的基础概念,尽量白话准确;提供了挖掘通用语言的两种方法,指导如何从需求文章中快速...转载 2019-07-10 21:09:12 · 1022 阅读 · 0 评论 -
领域驱动设计-- 分层架构
领域驱动设计的经典分层架构领域驱动设计在经典三层架构的基础上做了进一步改良,在用户界面层与业务逻辑层之间引入了新的一层,即应用层(Application Layer)。同时,一些层次的命名也发生了变化,将业务逻辑层更名为领域层自然是题中应有之义,而将数据访问层更名为基础设施层(Infrastructure Layer),则突破了之前数据库管理系统的限制,扩大了这个负责封装技术复杂度的基础层次的内...原创 2019-07-09 21:40:01 · 3965 阅读 · 0 评论 -
领域驱动设计-- 界限上下文协作
限界上下文通信边界对协作的影响确定限界上下文之间的关系不能想当然,需得全面考虑参与到两个限界上下文协作的业务场景,然后在场景中识别二者之间产生依赖的原因,确定依赖的方向,进而确定集成点,需要注意的是,限界上下文的通信边界对于界定协作关系至为关键。限界上下文的通信边界分为进程内边界与进程间边界,这种通信边界会直接影响到我们对上下文映射模式的选择。例如,采用进程间边界,就需得考虑跨进程访问的成本,如...转载 2019-07-08 21:56:22 · 1127 阅读 · 0 评论 -
领域驱动设计-- 界限上下文
界限上下文我们怎么去划分界限上下文我认为通过从业务边界到工作边界再到应用边界这三个层次抽丝剥茧,分别以不同的视角、不同的角色协作来运用对应的设计原则,会是一个可行的识别限界上下文的过程方法。从业务边界到我们的界限上下文,根据上图的过程展示梳理出来流程:在明确了系统的问题域和业务期望后,开发团队与领域专家经过充分地沟通与交流,可以梳理出主要的业务流程 — 这一阶段需要梳理和输出...原创 2019-07-07 21:06:40 · 2400 阅读 · 0 评论 -
运用领域场景分析提炼领域知识
用户故事敏捷开发人员对用户故事(User Story)绝不陌生,不过很多人并未想过为何极限编程的创始人 Kent Beck 要用用户故事来代替传统的“需求功能点”。传统的需求分析产生的是冷冰冰的需求文档,它把着重点放在了系统功能的精确描述上,却忽略了整个软件系统最重要的核心——用户。一个软件系统,只有用户在使用它的功能时才会真正产生价值。传统的功能描述忽略了在需求场景中用户的参与,因而缺乏了需求...转载 2019-05-23 08:38:39 · 475 阅读 · 0 评论 -
UML建模(DDD工具)
UML(用例图、类图、对象图、状态图、活动图、序列图、协作图)用例图 (Use Case)用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。参与者(Actor) 表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。用例(Use Case) 用例就是外部可见的系统功能,对系统提供的服务进行描述。用椭圆表示。子系...原创 2019-05-22 21:25:45 · 4831 阅读 · 0 评论 -
DDD 流程梳理
领域驱动设计提供了一整套战略和战术的方法论,这些方法论都是前辈们在无数的项目中总结出来的经验,我们在实际的项目中可以借鉴和学习。步骤:通用语言的提取和落地领域模型的表示上下文定义的边界领域的归属数据建模-- UML彩色建模 和 数据建模通用语言的提取通用语言的意义团队成员概念统一,理解一致,有文档落地。帮助产品快速理解用户需求 》帮助工程师快速理解业务需求 》帮助工程师...原创 2019-07-25 18:34:29 · 1121 阅读 · 0 评论