都在IT圈子混，为什么有些人可以成为一流高手，有些人搞了10年研发还只能靠吃老本儿过日子。简单来说，搞这行儿您得勤奋。特喜欢电影《霸王别姬》中的一句：“要想人前显贵，您就得背后受罪”。这人呐，就得学会自已个儿成全自个儿。好多DDD初级玩家上来就特喜欢聊“聚合”啊、“框架”啊、“事件溯源”啊，刘震云先生管这个叫“喷空”。其实他忘了一个重要的事儿：人家之所以能成为高手，那凭得是台下几年的“功夫”，靠得是“悟性”，不是光靠喷空得来的。这个圈子没有傻人，痴人太少。 有些人这辈子也成不了高手，不是不聪明，是“懒”！这个懒包含两面：一是身体上，就喜欢天天躺在床上刷抖音，搞王者荣耀；二是思想上，不愿意
为什么叫“戏说”呢？领域驱动设计出来的时候就有一种对于受众的调戏。书是读完了，您个人升华到了“看山非山，看水非水”的境界。再看一下落地代码，搞不好会仰天长啸：“这是我写的？”。佛家讲“空”，儒家讲“仁”，领域驱动讲“真”。真者，本质也。当您到了“真”的境界，就不会再与别人争论“到底是java还是C#好”，也不会再纠结“我这个设计合不合理啊？”。很多东西自然而然的就出来了。 回顾历史，领域驱动设计（Domain-DrivenDesign，简称DDD）大概源起于2004年。有个洋人叫EricEvans出了本书叫《Domain-DrivenDesign:TacklingComplexityin
关联对象无法封装的数据库开销引入关联对象上下文过载因富含逻辑而产生的过大类逻辑汇聚于上下文还是实体通过角色对象分离不同上下文的逻辑通过上下文对象分离不同上下文的逻辑架构分层DDD中的分层的问题基础设施层与领域层谁更稳定基础设施不是层能力供应商模式从基础设施到有业务含义的能力将技术组件进行拟人化处理使用能力供应商的多层架构能力供应商模式的缺点在落地DDD时，关联模型与软件实现总有让人纠结与苦恼的地方，引起这些苦恼的的主要原因是架构风格的变化。我们已经从多层单体架构时代，过渡到了云原生分布式架构，但所采用的建模思路与编程风格并没有彻底跟上时代的步伐。这种差异通常会以性能问题或是代码坏味道的形式出现
关联对象无法封装的数据库开销引入关联对象上下文过载因富含逻辑而产生的过大类逻辑汇聚于上下文还是实体通过角色对象分离不同上下文的逻辑通过上下文对象分离不同上下文的逻辑架构分层DDD中的分层的问题基础设施层与领域层谁更稳定基础设施不是层能力供应商模式从基础设施到有业务含义的能力将技术组件进行拟人化处理使用能力供应商的多层架构能力供应商模式的缺点在落地DDD时，关联模型与软件实现总有让人纠结与苦恼的地方，引起这些苦恼的的主要原因是架构风格的变化。我们已经从多层单体架构时代，过渡到了云原生分布式架构，但所采用的建模思路与编程风格并没有彻底跟上时代的步伐。这种差异通常会以性能问题或是代码坏味道的形式出现
业务建模解决问题还是定义问题业务建模的难点如何定义问题并让所有人接受如何在特定架构下实现模型学习业务建模的建议领域驱动设计领域模型对于业务系统是更好的选择知识消化知识消化的五个步骤模型与软件实现关联从贫血模型到富含知识的模型通过聚合关系表达业务概念修改模型就是修改代码统一语言是必要的吗统一语言是基于领域模型的共同语言修改代码就是改变统一语言一个简单的统一语言提案如何理解DDD将提炼知识的循环看做开发流程示例研发方与业务方的协同效应当讨论DDD时，我们到底在说什么迭代式试错建模法具有协同效应的工作方式价值观体系DDD的特点业务建模解决问题还是定义问题业务建模首先是一个定义问题的方法，其次才是解决
业务建模解决问题还是定义问题业务建模的难点如何定义问题并让所有人接受如何在特定架构下实现模型学习业务建模的建议领域驱动设计领域模型对于业务系统是更好的选择知识消化知识消化的五个步骤模型与软件实现关联从贫血模型到富含知识的模型通过聚合关系表达业务概念修改模型就是修改代码统一语言是必要的吗统一语言是基于领域模型的共同语言修改代码就是改变统一语言一个简单的统一语言提案如何理解DDD将提炼知识的循环看做开发流程示例研发方与业务方的协同效应当讨论DDD时，我们到底在说什么迭代式试错建模法具有协同效应的工作方式价值观体系DDD的特点业务建模解决问题还是定义问题业务建模首先是一个定义问题的方法，其次才是解决
文章简介在B端产品研发及项目实施中，DDD带给我们哪些思考？我们是如何应用的？本文不是科普贴，旨在分享我们的经历和思考。背景DomainDrivenDesign（简称DDD），又称为领域驱动设计，起源于杰出软件建模专家EricEvans在2003年发表的书籍《DOMAIN-DRINENDESIGN—TACKLINGCOMPLEXITYINTHEHEARTOFSOFTWARE》（中文译名《领域驱动设计—软件核心复杂性应对之道》）。随着2014年MartinFlower和JamesLewis的《Microservice》出版，微服务概念为业界所接受，DDD也被重新提起。人们发现，DDD里的领域、限
文章简介在B端产品研发及项目实施中，DDD带给我们哪些思考？我们是如何应用的？本文不是科普贴，旨在分享我们的经历和思考。背景DomainDrivenDesign（简称DDD），又称为领域驱动设计，起源于杰出软件建模专家EricEvans在2003年发表的书籍《DOMAIN-DRINENDESIGN—TACKLINGCOMPLEXITYINTHEHEARTOFSOFTWARE》（中文译名《领域驱动设计—软件核心复杂性应对之道》）。随着2014年MartinFlower和JamesLewis的《Microservice》出版，微服务概念为业界所接受，DDD也被重新提起。人们发现，DDD里的领域、限
牛B的人物，早已经厌倦了中英文混杂，他们更进一步，使用中英文缩写，对普通人进行降维打击。更厉害的，造就新的名词，并科普出去。有几项技术，我从心底里鄙视和厌恶，但每次在技术方案中，都默默的把它们加进去，而且给足了它们分量。因为它们对于方案的成功与否，起着重要的概念性指导作用。它们就是中台、低代码，以及DDD。这三个不同领域中的技术，肩负着同样的责任，那就是往死里忽悠。这三个词，很伟大，它们有一个共同点，都是很容易说服非技术但能决策的人员，然后向下铺开，非常具有营销型，是职业经理人和CTO的最爱。也是咨询类公司的最爱。这些玩意儿，有的可以忽悠大公司，有的可以忽悠小公司，反正谁也别想逃掉。但毒瘤如果
牛B的人物，早已经厌倦了中英文混杂，他们更进一步，使用中英文缩写，对普通人进行降维打击。更厉害的，造就新的名词，并科普出去。有几项技术，我从心底里鄙视和厌恶，但每次在技术方案中，都默默的把它们加进去，而且给足了它们分量。因为它们对于方案的成功与否，起着重要的概念性指导作用。它们就是中台、低代码，以及DDD。这三个不同领域中的技术，肩负着同样的责任，那就是往死里忽悠。这三个词，很伟大，它们有一个共同点，都是很容易说服非技术但能决策的人员，然后向下铺开，非常具有营销型，是职业经理人和CTO的最爱。也是咨询类公司的最爱。这些玩意儿，有的可以忽悠大公司，有的可以忽悠小公司，反正谁也别想逃掉。但毒瘤如果
