领域驱动第19页

戏说领域驱动设计（廿二）——聚合

聚合的自白大家好，我是聚合，在你们的期盼之下我终于出来了。其实早就想和大家见一面，不过作者每天总想着水流量，到现在才让我出来。他把实体和值对象这两个我家庭内的成员先介绍让我感觉非常的不公平。没有国哪有家？没有家庭，生活也不会温暖。好多的工程师眼里只想着实体他们，让我难受的想要哭泣。明明是由于我的存

SKevin·2022-04-11 09:00

领域驱动设计入门与实践 [下]

「PhoneNumber-充血模型」与「POJO类-贫血模型」不难理解，笔者在「领域驱动设计入门与实践-上」中已对其做过介

·2022-04-07 18:13

戏说领域驱动设计（廿一）——领域服务

实体对象和值对象都写完了，本想开始写资源仓库顺便把工作单元再搞搞。不过有一点麻烦的是我不太想把工作单元作为单独的一章来写，一是这东西网上相关的内容太多；二是有的时候使用Spirng的事务就解决了，没觉得有多大作用。不过先不纠结这些，还是按本章的主题写领域服务吧，这好讲，谁不喜欢简单的东西。一、为啥

SKevin·2022-04-07 17:00

领域驱动模型DDD（二）——领域事件的订阅/发布实践

前言凭良心来说，《微服务架构设计模式》此书什么都好，就是选用的业务过于庞大而导致代码连贯性太差，我作为读者来说对于其中采用的自研框架看起来味同嚼蜡，需要花费的学习成本实在是过于庞大，不仅要对书中的内容进行了解，还要去学习作者框架用法，最可恶的是官方文档还写得十分简洁。不要跟我说《微服务架构设计模

阿波罗的手·2022-04-07 14:00

戏说领域驱动设计（二十）——值对象

值对象这个东西在DDD里算是比较抽象的，好多人学了半天也学不明白。我这种聪明人也费了好大劲，总算苦心人天不负，现在也能用个有模有样了。战术模式中不论是领域服务、对象工厂还是资源库，基本上您能听懂是什么意思，在BO层中所承担的角色也比较明确，唯独这个值对象有点坑爹。遥想当年我在使用C#的时候，里面有一个值类型，与别人讨论的时候经常会把这个东西搞混，就我现在写东西还下意识把“值对象”写成“值类型”呢。

SKevin·2022-04-02 17:00

戏说领域驱动设计（十九）——外验

内验是针对领域模型自身的验证，其验证规则也是由领域模型自已来完成，只是触发的时机可能在工厂中也可能在构造函数中。与内验对应的当然就是外验了，这是用于对用户的输入和业务流程的前提或得更专业一点叫“前置条件”的检验。如果细化一点，可以将外验分成两个情况：用户输入和业务流程的前置条件。情况不同验证的方式也不一样，下面让我们展开了细聊。对了，额外多说一句，此处的“内验”和“外验”是我为了说明问题所起的名称

SKevin·2022-03-31 08:00

DDD领域驱动设计特点及难点

DDD的特点主要是定位于解决复杂性，1、发现和理解问题介绍两周发现问题并能就理解问题达成共识的方式：面对面协作建模和阅读代码逆向工程建模。2、领域即边界领域即边界，边界考分类，分类需要从内外部入手。3、解决复杂性两种方法：拆解松耦合的组件+使用容易让人明白的套路表达出来。首先,DDD通过引入领域或是子域、有界上下文来划分边界，边界一旦分好第一步就完成。第二步：引入各种模式名词比如聚合，实体，值对象

任玉·2022-03-30 09:03

DDD(领域驱动设计)

1DDDDomainDrivenDesign(领域驱动设计,DDD)，不是一种架构，而是一种架构方法论，是一种拆解业务、划分业务、确定业务边界的方法，是一种领域设计思想。

小飞哥wzf·2022-03-30 09:33

DDD-建模过程分析

EricEvans的“Domain-DrivenDesign领域驱动设计”，简称DDD，EvansDDD是一套综合软件系统分析和设计的面向对象建模方法，其核心就是建立正确的足够精良且符合业务需求的领域模型

最爱下雨天啊·2022-03-30 09:33

领域驱动设计(DDD)实践之路(二)：事件驱动与CQRS

本文首发于vivo互联网技术微信公众号链接：https://mp.weixin.qq.com/s/Z3uJhxJGDif3qN5OlE_woA作者：wenbozhang【领域驱动设计实践之路】系列往期精彩文章

vivo互联网技术·2022-03-30 09:23

领域驱动设计（DDD）入门&概要

我们为什么需要领域驱动设计在说什么是领域驱动设计之前，我觉得需要先说一下我们为什么需要领域驱动，我个人认为领域驱动设计对于研发来说改进点主要有下面三个：从大泥球风格中解脱出来，控制代码复杂度回归面向对象编程本质

永远_不会懂·2022-03-30 09:52

业务中台总体架构介绍与交易业务中台核心设计

业务中台总体架构介绍与交易业务中台核心设计架构总原则：电商中台:服务接入层：公用基础组件：云服务&设施容器层业务前台产品：稳定和安全保障系统工程结构：架构总原则：大中台+小前台的架构思路业务中台采用领域驱动设计

凌飞安·2022-03-30 09:42

浅谈我对DDD领域驱动设计的理解

转自https://www.cnblogs.com/netfocus/p/5548025.html这哥对这个问题解释得非常透彻，借此自己也学习一下。从遇到问题开始当人们要做一个软件系统时，一般总是因为遇到了什么问题，然后希望通过一个软件系统来解决。比如，我是一家企业，然后我觉得我现在线下销售自己的产品还不够，我希望能够在线上也能销售自己的产品。所以，自然而然就想到要做一个普通电商系统，用于实现在线

我是小红花·2022-03-30 09:10

简析DDD（领域驱动设计）及落地

DDD（领域驱动设计）是对软件所涉及到的领域进行建模，以应对系统规模过大时引起的软件复杂性的问题。而在微服务微应用蔚然成风的今天，他们共同体现的分而治之的思想，使得领域建模显得尤为重要。

远光九天云平台·2022-03-30 08:32

DDD领域驱动设计落地实践（十分钟看完，半小时落地）

一、引子不知今年吹了什么风，忽然DDD领域驱动设计进入大家视野。

Java技术那些事儿·2022-03-30 08:00

DDD 领域驱动设计落地实践系列：工程结构分层设计

引言前面几篇文章中，笔者给大家阐述了DDD领域驱动设计的三大过程，重点围绕如何通过战略设计与战术设计进行DDD落地实践进行了详细的讨论，但是还没有涉及到工程层面的落地。

慕枫技术笔记·2022-03-30 08:59

DDD领域驱动设计落地实践系列：初识DDD

引言笔者在经历的很多项目中都使用了DDD领域驱动设计进行架构设计，尤其是在业务梳理、中台规划以及微服务划分等方面，DDD是重要的架构设计方法论，对平时的架构设计有非常好的指导作用。

慕枫技术笔记·2022-03-30 08:58

DDD领域驱动设计落地实践系列：战略设计和战术设计

引言通过前面的文章介绍，相信大家对于什么是DDD有了初步的了解，知道它是一种微服务的架构设计方法论，为我们解决如何建立领域模型，如何实现微服务划分等提供了方向和指导。但是对于如何具体落地使用DDD，可能大家还是一脸懵B的状态，因此从本文开始以及后面的文章将对如何进行DDD落地进行详细的阐述。在这其中还是会涉及到DDD中的一些重要概念，原本想着在一篇文章中介绍所有的概念，但是我觉得，概念总是在它该出

慕枫技术笔记·2022-03-30 08:58

DDD 领域驱动设计落地实践：六步拆解 DDD

引言相信通过前面几篇文章的介绍，大家对于DDD的相关理论以及实践的套路有了一定的理解，但是理解DDD理论和实践手段是一回事，能不能把这些理论知识实际应用到我们实际工作中又是另外一回事，因此本文通过实际的业务分析把之前文章中涉及的理论和手段全部带着大家走一遍，我想通过这种方式，让大家实际的感受下DDD落地过程中会遇到哪些问题以及我们应该怎样去解决这些问题。项目需求信息这里还是大家比较熟悉的电商场景来

慕枫技术笔记·2022-03-30 08:25

领域驱动设计入门与实践[上]

概念解读领域驱动设计-DDD（Domain-DrivenDesign）是一种基于领域知识来解决复杂业

·2022-03-29 19:23

配置ABP框架使用对象映射

DTO和实体实体实体是领域驱动设计(DomainDrivenDesign)中的概念，实体通常一一映射某些对象的固有属性，最常使用的是关系型数据库中的表。

·2022-03-29 18:47

戏说领域驱动设计（十八）——内验

验证在我们现实的生活中非常常见，比如您找工作得先整个面试验证你的能力是否靠谱；找对象得先验证下对方的颜值和升值空间。有些工程师写代码从不验证，我觉得是有三个原因，一是意识不够，过于相信前端或外部服务；二是个人缺少主动思考的能力；三是团队负责人的问题，您都当了领导了为什么不制定一些基本开发规则给团队树规矩。实际上，验证这个事情说简单也的确不难，不就是个值判断吗？可如果想把这个事情做好还真是一个需要值

SKevin·2022-03-29 08:00

领域驱动模型DDD（一）——服务拆分策略

前言领域驱动模型设计在业界也喊了几年口号了，但是对于很多“务实”的程序员来说，纸上谈“术”远比敲代码难得太多太多。

阿波罗的手·2022-03-23 22:00

戏说领域驱动设计（十七）——实体实战

上一节中讲了实体的一些概念，作为DDD中最为复杂的组件，想用好了还需要在实践中慢慢去摸索，都是摸爬滚打过来的。本章着重演示一些实体相关的代码，通过建立一个基类和通用方法，能让您在开发过程中少写一些重复的代码同时也减少在使用第三方开源框架时的学习成本。此外，是从0写代码，不需要付出太多的精力便可以加深自身对理论的理解。友情提示一下，您在看的同时也需要回忆一下前面文章中所说的各类规则、限制，理论与实践

SKevin·2022-03-23 10:00

领域驱动编程，代码怎么写？

简介：相较于大家熟练使用的MVC分层架构，领域驱动设计更适用于复杂业务系统和需要持续迭代的软件系统的架构模型。

·2022-03-21 16:32

戏说领域驱动设计（十六）——实体概念

现在开始正式的进入战术部分，我看前面发的一些文章，只要有代码的阅读量就高，没代码的就差太多了，难道是因为平台只要看到代码才会加强推荐吗？真要是这样那我是真醉了，其实学习DDD光看代码还真不行，需要很多理论支持的。如果您是新的读者我建议先把前面的内容都翻看一下，至少得有一些理论依据作支撑后面学习起来才会更有效率。本章主要讲解实体，属于战术部分最为核心的内容。有人说聚合重要，但聚合也是实体，重要度都高

SKevin·2022-03-21 08:00

架构方面学习笔记（3）-前端架构设计

2022.02.08今天读了一篇关于前端整洁架构的设计，因此对其中的内容进行了一些整理以及我自己的思考，后续阅读《领域驱动设计》后可以加入更多的内容。

LynnWonderLu·2022-03-18 03:26

戏说领域驱动设计（十五）——内核元素

必然是领域模型啊，比如实体、值类型、业务服务等，您别忘了咱们讲的是领域驱动设计。具体可参看如下图所示的领域模型层（后续简称BO层）中的元素。这里面东西较多，基乎每一种都可以开一章来讲，也就是可以

SKevin·2022-03-17 09:00

戏说领域驱动设计（十四）——补遗

《领域驱动设计:软件核心复杂性应对

SKevin·2022-03-15 09:00

商品领域ddd_系统规模大、软件复杂？试试 DDD 架构设计！

作者|一切即心责编|伍杏玲VaughnVernon在《领域驱动设计精粹》书中这样讲到：“一旦创新停滞并进入维护期后，我们该如何继续维持通用语言？

weixin_39559804·2022-03-15 07:25

戏说领域驱动设计（十三）——核心架构

在做了两章铺垫后本章再续写第九章。我们之前介绍过了好几种架构模式，那么本章只挑一种往死了整，这个架构其实就是在DDD书中所介绍的经典四层的变更版。这里面需要注意一点，四层架构是洋葱架构的一部分，尽管洋葱型已经是微服务架构系统中一种事实上的标准，但我们不会对各类适配器做重点介绍，那些东西一般都是开源的组件或者没有业务逻辑的组件比如DAO。再说了，您都已经学习DDD了还需要我再讲解什么是DAO吗？所以

SKevin·2022-03-14 10:00

领域驱动在本地生活的实践

导读本次分享的主题主要是关注两个方面，当我们面对一个业务的时候，一方面怎么使用领域驱动去指导去做整体的架构的设计，怎么进行微服务的建设(排除基础设施等的应用架构)；另外一方面是结合现有的软件设计生态去实现系统

·2022-03-10 13:36

微服务与分布式的一些设计原则(转)

微服务设计原则第一条：要领域驱动设计，而不是数据驱动设计，也不是界面驱动设计。微服务设计首先应建立领域模型，确定逻辑和物理边界以及领域对象后，然后才开始微服务的拆分和设计。

~起风了·2022-03-09 10:46

戏说领域驱动设计（十二）——服务

上一章讲解了软件设计中主要用到的三个设计模型，本节讲解三个服务。等咱们这次都讲完了再最后进行一次归纳，即：系统开发流程中的三模型、软件设计中的三模型和三个服务，我习惯管这个叫3*3*3。看完了您就会知道我为什么常说软件设计这活是朴素的，没那么多弯弯绕，只是因为我们在学习过程中没有做思考和归纳。设计模式的那四个哥们儿不也是根据其经验总结出了流传至今且经久不衰的23个模式（其实常用的也没几个）以及6个

SKevin·2022-03-09 08:00

当今微服务盛行之架构师必经之路-领域驱动设计-下

DDD架构传统分层架构分层架构设计就是为了帮助我们达到高内聚、低耦合复用性设计和扩展性设计。整洁架构、CQRS、六边形架构等微服务架构都旨在实现“高内聚低耦合”，而分层架构基本原则是每层只能与位于其下方的层发生耦合。分层架构又分为两种：严格分层架构(StrictLayersArchitecture)，某层只能与其直接下层耦合。松散分层架构(RelaxedLayersArchitecture)，允许

itxiaoshen·2022-03-07 23:00

领域驱动设计之旅

1.背景软件复杂性这一问题，几乎是“软件危机”的同义词。上世纪60年代因为计算机硬件的发展，使开发功能更强大的软件成为可能，软件的规模越来越大，越来越复杂。因为开发软件的方法论、技术手段较为落后，软件的开发不甚顺利，存在诸多问题，当时学术界定义了“软件危机”一词，用以描述这一现象。随后的几十年间，涌现了各种各样的应对软件危机的方法，这些方法有的从软件的生命周期角度优化软件的开发过程，有的考虑如何设

Ethan遗忘·2022-03-07 08:59

戏说领域驱动设计（十一）——纠偏

今儿写这个题目胆子有点大，不过还是得冒险整一篇（我怕您看完了骂我），一是出于经验分享，另外则是为了后面我们讲案例的时候做好铺垫。好的代码需要注意的事项其实挺多的，您真让我一骨脑儿都列出来可能也差点意思，所以遵照我们常态化歪楼的习惯，我是想到哪写到哪儿。我没事儿的时候就喜欢看别人写的文章，也喜欢看书，收获还是挺多的，不过岁数大了忘性也大，记不住。可有一个事情我记得倍儿清楚：咱们搞技术的尤其是后端开发

SKevin·2022-03-07 08:00

当今微服务盛行之架构师必经之路-领域驱动设计-上

DDD基础引言>：全书围绕着设计和开发实践，结合若干真实的项目案例，向读者阐述如何在真实的软件开发中应用领域驱动设计。

itxiaoshen·2022-03-06 19:00

戏说领域驱动设计（十）——杂谈

各位看官司好，领域驱动设计转眼就写到了第十章，内容虽不多，但的确下了一番的心血。希望您在此系列中已经得到了收获，哪怕是一丁点，也是DDD这个圈子的星星之火。

SKevin·2022-03-04 09:00

戏说领域驱动设计（九）——架构模式

本节开始进入DDD的战术阶段，首先要讲解的必然是DDD中的架构，毕竟程序员就喜欢这个……不过这里的架构不同于我们常说的微服务架构、单体架构、无服务架构或服务网格。不严谨来讲，上述4种为涉及到系统结构、部署方式、服务器架构等更为全面的、包含软、硬件等内容的宏观系统架构（这个不在我们的主要范围内，主要是以个人这点水平吹个牛还行，不成系统的）。而我们要讲的更多的是聚焦于基于BC的架构模式，也就是BC在落

SKevin·2022-03-03 14:00

EF使用数据注解特性创建表结构

设计应用的另一种方法就是以领域为中心的方式（领域驱动设计DDD）。DDD是一种由上而下

·2022-03-03 12:53

微服务架构设计和拆分

微服务架构的设计原则拆分足够微轻量级通信领域驱动原则单一职责原则DevOps(开发/运维)及两个披萨不限于技术栈微服务模块设计服务拆分服务注册服务发现服务消费统一入口配置管理熔断机制自动扩展微服务拆分的意义易于实现易于维护易于部署易于更新微服务拆分的方法横向拆分

wunianisme·2022-03-03 09:38

戏说领域驱动设计（八）——边界

我们在前面花了大手笔聊子域与限界上下文，不知道作为读者的您的感受是什么。当然了，我可不是郭德纲自己给自己叫好。您应该也发现了一个规律，此两节的内容其实都是在讲“分”：子域从业务上划小，BC从物理上进行划小。虽然说BC属于分析模型，但那东西只要一确定您可就得按这个方案进行开发了，所以说其确定了物理上的边界并无问题。既然是“分”，就使得每一个被划小的单元都有了自己的专属地盘儿或者叫势力范围。“文明”是

SKevin·2022-03-01 08:00

戏说领域驱动设计（七）——限界上下文——延伸

上一章是真的不好写，吃奶的劲儿都快使出来了。本章计划是查缺补漏，对BC的内容进行补充。您也看到了，战略设计作为DDD中最重要的一部分，只写一节就完事儿也差点意思。不过您也别期望太多，咱这个文章本来就是自身经验的总结性，我是假设您有一定的DDD基础，所以不会按照书的那种程度去写，否则还不如直接看书呢。再说了，文章的读者什么层级都有，我要是再啰里啰嗦把书的内容都事无巨细的都写下来一是会造成您阅读的负担

SKevin·2022-02-24 11:00

戏说领域驱动设计（六）——限界上下文——设计

限界上下文（简称BC）是一个很难讲的部分。我寻思着是不是再多找一找文章，看看其它人怎么讲的，但犹豫再三还是决定按自已的理解去聊，各种找材料就有点剽窃的行为了。至于说的是否正确，您务必也要做好判断，毕竟每个人都会有自己的理解。做为温故而知新的一部分，在此把前面总结的BC的特点再重复一下，也不是为了凑字儿，DDD这东西就得靠多多的啰嗦才能记得住，毕竟概念忒多。此外，为提升您的阅读体验，限界上下文分为两

SKevin·2022-02-22 14:00

难以置信，一本普普通通的彩色手册，竟把微服务容器 K8S讲清楚了

在软件构建方面，微服务倾向于使用面向服务和领域驱动设计（DomainDrivenDesign）的方法论，将现实中的问题投影到对象的世界。“抽象、分解、扩展、复用”是常见的微服务构建系统的内功心法。

写代码的珏秒秒·2022-02-22 12:09

DDD领域驱动设计的项目实践

Domain-DrivenDesignDDD的概念众所周知，各个文章中的基本概念也都大同小异。这里就不再累述了。DDD最大的好处是使用领域通用语言（UBIQUITOUSLANGUAGE）将原先晦涩难懂的业务通过领域概念清晰的显性化表达出来。写这篇文章的目的在于学习怎么使用DDD来降低应用的复杂度，增加框架的可扩展性。本文主要阐述了我在项目中的思考过程和架构实现。Anyfoolcanwritecod

小猫无痕·2022-02-21 19:16

DDD-领域驱动设计简谈

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

莱布尼茨·2022-02-21 14:00

基于DDD的微服务设计和开发实战

本文是基于DDD的微服务设计和开发实战篇，通过借鉴领域驱动设计思想，指导微服务项目团队进行设计和开发（理论篇详见《当中台遇上DDD，我们该如何设计微服务》）。

欧创新·2022-02-21 12:50

DDD在社交网络的实战

什么是DDD领域驱动设计（Domain-Driven-Design）作为一种软件开发方法，它可以帮助我们设计高质量的软件模型。

望望hope·2022-02-21 12:27

推荐频道

领域驱动