关于UML、《软件方法》各种评论很多，评论、疑问或质疑的内容没有到一定水平或者造成巨大影响，我基本上是不回应的。我回应的问题是怎样的，可以看《UMLChina公众号文章精选》的“精品文章”和“答疑”部分。
潘老师：我正在看*老师的“**领域驱动设计”，有个问题请教一下，这副图上的不变量觉得很别扭，是不是多余了？您有没有进一步学习不变量的资料推荐呢，我也在追更您的下册，里面似乎没有说到。
百度网盘下载试看片段：https://pan.baidu.com/s/1AR6G2QUf4F6uNkvWCMIKNA，提取码：umlc
本次演讲是我创作GitChat课程「领域驱动战略设计实践」和「领域驱动战术设计实践」这两年来，随着对领域驱动设计的深度理解，结合自身项目经验总结的领域驱动设计知识体系。
领域驱动设计（Domain Driven Design，DDD）确实已不再青春，从 Eric Evans 出版了划时代的著作《领域驱动设计》至今，已有将近十五年的时间，在软件设计领域中，似乎可以称得上是步入老年时代了。
通过比较领域驱动设计和数据驱动设计，探讨为何基于数据库进行设计容易催生出贫血模型与事务脚本，指出领域驱动设计与数据驱动设计的不同之处在于限界上下文和聚合。
本文尝试指出领域驱动设计的四个不足。目前我们采用的领域驱动设计，其主线是Eric Evans提出的所谓领域驱动设计元模型。该元模型因其高度的概括性与松散性，故而能够随着时间推移历久不衰。但也正因为此，使得它在指导领域驱动设计落地时，缺乏规范性和实践意义，更多需要凭借经验才能成功实施领域驱动设计。
pdf文件下载：http://umlchina.com/training/umlchina_ddd_02_domainmodeling_structure.pdf
pdf文件下载：http://umlchina.com/training/umlchina_ddd_01_overview.pdf
本文是我即将在GitChat发布的领域驱动设计第二篇「领域驱动战术设计实践」的开篇词。本课程预计会在5月初发布，内容承接「领域驱动战略设计实践」，敬请关注。
子领域、限界上下文、分层架构与聚合皆为领域驱动设计的核心元模型，分属战略设计和战术设计，贯穿了从问题空间到解空间的全过程。
前些年一直在做微软的解决方案实施与软件开发的工作。在学习、项目实施、开发与管理的过程中学到了别人不少好的东西，也自身总结了大量的经验，希望能够通过一个系列来跟大家分享关于软件开发方面的内容。 这个开发系列的由来是这样的，两年前作为一个软件公司的技术总监，完成了一个企业的ERP系统开发，我在这个项目中担当了架构师的角色，主要负责核心技术架构搭建与业务建模的工作。这个系统的规模达到13个人12个月，涉及到企业的各个方面，包括客户关系管理、销售管理、采购管理、项目管理、财务管理、行政与人力资源管理等，业务流程70
以下图片摘自《HIS内核设计之道——医院信息系统规划设计系统思维》，任连仲、陈一君、郭旭、黄以宽 主编
Allan(35***369)11:55:33 潘老师 ，在EA工具里， 点击可以穿透到时序图，怎么设置？ Allan(35***369)12:49:40 就是图标里的眼镜怎么出来的
领域驱动设计（Domain Driven Design，DDD）是由Eric Evans最早提出的综合软件系统分析和设计的面向对象建模方法，如今已经发展为一种针对大型复杂系统的领域建模与分析方法。它完全改变了传统软件开发工程师针对数据库进行的建模方法，从而将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为，通过合理运用面向对象的封装、继承、多态等设计要素，降低或隐藏整个系统的业务复杂性，并使得系统具有更好的扩展性，应对纷繁多变的现实业务问题。
述说撰写《解构领域驱动设计》一书的心路历程，三年磨一剑的认真态度与艰辛苦楚，如今写作完毕，也算是苦尽甘来。本书将由人民邮电出版社异步图书社区出版，敬请关注公众号的后续消息。
相信很多朋友对领域驱动设计会有这样或那样的困惑，比如领域驱动设计是什么？它在工作中有什么作用？为什么国内关于这方面的书籍少之又少？为了解决这些困惑，有幸邀请到专家张逸老师来聊聊领域驱动设计，下面是GitChat独家采访记录。
因为微服务，人们似乎才重新发现了领域驱动设计的价值，可惜的是，对于这样一个在国外 IT 圈享有盛誉并行之有效的设计方法学，国内大多数的技术人员却并不了解，也未曾运用到项目实践中。
领域驱动设计，方法论是为了解决软件核心复杂性的。也就是说软件业务越来越复杂了，领域驱动设计可以让事情变得简单。而实际情况是：领域驱动设计的门槛很高，没有很深厚的面向对象编码能力几乎不可能实践成功。
作者 | 张逸 最近重读Eric Evans的经典《领域驱动设计》，正如Eric提倡我们要去发现隐式概念一般，这次重读也让我发现了许多隐藏的DDD知识。恰好今日有朋友咨询我一些DDD问题，好似激活了触发器，随着问题的解答，我倒是在回答过程中又把这些知识梳理了一遍，才有了这篇杂记。 问题一：Repository的问题 怎么看待DDD中的Repository？我们必须把握一个根本的底线，就是采用DDD方式设计Repository时，一定要忘记所有与数据访问有关的技术实现细节。Repository接口属于领域层
在战略层次，需在领域驱动架构风格的约束和指导下考虑限界上下文之间的协作，思考并决策限界上下文的通信边界，思考从单体架构向微服务架构的演进，同时，因为进程间通信引起的诸多影响，需评估分布式通信、事务以及受技术因素驱动的命令查询职责分离模式是否对领域模型造成了影响。
本文主要涉及境外出行、商场团购和内容商业化等三类交易业务场景。在大众点评App里，在境外城市站有美食、购物、商场、景点、门票、当地玩乐等频道入口，可以购买境外出行交易产品，在境内的逛街/商场频道可以找到商场团购优惠以及商场团购代金券。
比起严谨的建模方法，伪创新更受欢迎，因为它迎合了“广大开发人员”呆在舒适区的需要。
DDD（领域驱动设计）话语中有“通用语言（Ubiquitous Language）”的用语，这是一个伪创新。
领域驱动设计(Domain Driven Design,DDD)是Eric Evans提出的综合软件系统分析和设计的面向对象建模方法。它改变了传统软件开发工程师针对数据库进行的建模方法，从而将要解决的业务概念和业务规则转换为软件系统中的类型一级类型的属性与行为，通过合理运用面向对象的封装、继承和多态等设计要素。仔细想想，我们在开发项目时，是不是只是思考数据库的设计，围绕着数据库进行各种操作的呢！
每个项目由若干活动组成，每项活动又由许多任务组成。一项任务消耗若干资源，并产生若干工件。工件有代码、模型、文档等。
设计并不是把系统分解成能够编码的小块就行，如果是这样，同一个系统，让100个人来分解，可能有100种分法。选择这个选项可能会导致系统的结构会朝着“编码人员怎么爽怎么来”的方向走。
架构是为了解决业务问题而产生的，没有了业务，架构就没有了存在的前提！在解决同一个业务问题的前提下，更高效更低成本的架构，会淘汰低效高成本的架构。DDD让架构更高效，打破了架构和业务之间的隔阂。其流行的意义就在此。
3 [单选题]以下这些经常在开发团队里使用的词汇，都是不严谨的。其中_______混淆了需求和设计的区别。
本文从需求分析到API设计，试图描述领域驱动设计的过程及思想。同时也能看的出领域驱动设计并不是孤立存在的，它为解决开发团队和业务人员之间沟通而生，进而驱动微服务的划分以及API的设计。
[改为19:30上课*5天]8月31-9月4日晚剔除伪创新的领域驱动设计-网络公开课
大约公元前800年至前200年间，中国、希腊、印度和以色列的文明几乎在同一时期兴起，这被称为人类文明的轴心时代。不同文明展现出了不同的风貌。中国古代文化强调辩证逻辑，重视变化、联系和综合的思维方式，同时又有“子不语怪力乱神，六合之外存而不论”的唯物主义倾向。古希腊则重视严格的推理和分析，孕育了形式逻辑和公理化的数学体系。印度在婆罗门和佛教哲学中，从另一个方向将辩证法、逻辑和语言学推向极致。以色列的先知则创立了一神论的犹太教和政教合一的社会体制。
在"延续"、"变更"时，和"新发"是一样的，也有三种情况。这有没有好的办法来画，还是只能重复画三遍？ 四爷(473***93) 10:03:28 表达清楚了就OK了吧？ lihongwei(627***07) 10:04:43 我想咨询一下：除了重复画三遍，在EA中是否可引用。似乎不行。 我想到的办法是注释一下 下面两个不画了
有一个地方想和您商榷，这张图上说对象树是译者的臆想，我觉得译者译成对象树也对，因为聚合根和其他对象是一对多关系，您觉得呢？
一般认为架构师的主要职责首先是组织架构活动，然后是制定架构方案。制定架构方案我们一般都能很好的理解，那什么是组织架构活动呢。
最先介绍领域驱动设计（domain-driven design）的是在程序员 Eric Evans 2004年出版的《领域驱动设计:复杂软件核心复杂应对之道》书籍中，领域驱动设计是领域概念的扩展和应用，并且将它应用在软件开发中。它的目标是将软件相关部分连接到不断发展的模型中，以此更容易创建复杂的应用。
领域驱动设计，近年来受到技术圈的广泛追捧，主要得益于微服务技术的发展。一千个读者有一千个哈姆雷特，而不同的人往往对这种理论有不同的看法。如果问一个.net开发者领域驱动是什么，大概他会说是abp架构。ABP架构作为完全按照领域驱动设计思想构建的技术架构，目前得到了社区的广泛追捧。然而，领域驱动架构和领域驱动设计，依然是道和术的区别，开发者在学习领域驱动架构的同时，也应该了解领域驱动设计。那么领域驱动设计究竟是什么的东西？由于时间和篇幅有限，我无意通过代码介绍如何实现一个领域驱动的功能，而是希望把领域驱动设计的基本思路进行梳理，期待能通过我的梳理，抛砖引玉，给大家带来启迪。
如果有人不了解人体的内部结构，就自称医生，声称自己能给人开腹割掉发炎的阑尾，甚至还能开胸给冠心病人做心脏搭桥，你信吗？
这篇文章讨论领域驱动设计(DDD)，DDD是建立在面向对象分析设计上开发软件的一种方法。 通过这篇文章我们解释什么是领域驱动设计，在现代开发周期中如何实现，使用DDD的优点和缺点。
封面图：张子瞻的绘画，用丙烯颜料表达了蓝色的海、白色的波浪、棕黄色的沙滩以及墨绿色的树林。
领域驱动设计（Domain-Driven Design，简称DDD）是软件开发领域的一种设计思想，由埃里克·埃文斯（Eric Evans）在他的著作《领域驱动设计：软件核心复杂性应对之策》（Domain-Driven Design: Tackling Complexity in the Heart of Software，2003）中首次提出。这种设计思想重视将实际业务问题映射到软件设计中，以解决复杂业务场景带来的软件开发问题。下面让我们来探索领域驱动设计的发展历史。
在此前的两篇文章《研发深恶痛绝，业界持续热捧，DDD 到底是啥？》《从4万行代码降到1.8万，腾讯视频竟然用DDD做架构重构？》中，我们详细拆解了 DDD 的理论发展和实际落地过程中的量化评估方案，为大家深入浅出地揭开了 DDD 的神秘面纱。在本篇文章中，我们将重点阐述 DDD 的核心概念与关键方法。
应对复杂度的挑战，或许是构建软件的过程中唯一亘古不变的主题。为了更好地应对软件复杂度，许多顶尖的软件设计人员与开发人员纷纷结合实践提出自己的真知灼见，既包括编程思想、设计原则、模式语言、过程方法和管理理论，又包括对编程利器自身的打磨。毫无疑问，通过这些真知灼见，软件领域的先行者已经改变或正在改变我们构建软件的方法、过程和目标，我们欣喜地看到了软件的构建正在向着好的方向改变。然而，整个客观世界的所有现象都存在诸如黑与白、阴与阳、亮与暗的相对性，任何技术的发展都不是单向的。随着技术日新月异向前发展，软件系统的复杂度也日益增长。中国有一句古谚：“道高一尺，魔高一丈。”又有谚语：“魔高一尺，道高一丈。”究竟是道高还是魔高，就看你是站在“道”的一方，还是“魔”的一方。
正所谓有人的地方就有江湖，有设计的地方也一定会有架构。如果你是一位软件行业的老鸟，你一定会有这样的经历：一个业务的初期，普通的 CRUD 就能满足，业务线也很短，此时系统的一切都看起来很 nice，但随着迭代的不断演化，以及业务逻辑越来越复杂，我们的系统也越来越冗杂，模块彼此关联，甚至没有人能描述清楚每个细节。当新需求需要修改一个功能时，往往光回顾该功能涉及的流程就需要很长时间，更别提修改带来的不可预知的影响面。于是 RD 就加开关，小心翼翼地切流量上线，一有问题赶紧关闭开关。
业务建模时，心中的摄像机应该一路跟随实现业务用例的流程去拍摄，把拍到的故事如实画出来，各个系统只是流程中的一个零件。建模人员常犯的错误就是把自己要开发的系统看得比天还大，把摄像机固定在自己要开发的系统的旁边。
目前我在看两本书《领域驱动设计精粹》和《实现领域驱动设计》，前一本比较薄，不到150页，后一本就非常厚实了，有500多页，那么读起来可能就会显得有点心理障碍，但如果要想更多了解DDD，还是要以第二本为主，第一本可以作为概要性阅读。
断断续续的也有在闲余时间接触领域驱动设计的相关知识，因为目前在工作中更多的还只是一名 crud boy，因此目前也只是对其中的某些知识点有知晓，实际使用的比较少，仅此而已。因此，趁着这个春节假期，整理了一下自己的 github 帐号，同时结合自己定的学习计划以及自己的期望发展方向，决定从一个真实的案例来梳理领域驱动的相关知识。
冯友兰治哲学，提出“照着讲”和“接着讲”的方法论。近两年，我断断续续梳理出关于领域驱动设计的两个 PPT：《领域驱动设计》和《领域驱动设计四论》。前者的内容主要是关于 DDD 经典著作的读书笔记，可视为照着讲，以证明自己学有所本，讲的不是野狐禅；后者则是在继承的基础上所做的创新阐释，可视为接着讲，发前人之未发。本文重点围绕《四论》展开，从四个方面梳理出 DDD 的整个逻辑脉络。
我在GitChat上最新开通了一个Chat，主题为：限界上下文的菱形对称架构。为有利于搜索，更名为：领域驱动设计的菱形对称架构，但主要针对的是领域驱动设计的核心模式：限界上下文（Bounded Context）。
由于本次研究需要采集大量工程实践的调查样本，故而钟博士与其他研究者共同拟定了附于文末的调查问卷。为了更好地获得来自领域驱动设计推进一线的真实反馈，我诚挚希望各位读者能够踊跃参与本次调查，发表您的真实意见。参与者并有机会获得由人民邮电出版社异步社区赠送的《解构领域驱动设计》实体书，后期还可以收到我们整理后的调研报告内容！多谢捧场！
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
腾讯会议
