在我看来并不是MVC的基础上增加领域层，使用充血模型，解耦基础服务，我的代码就符合DDD了。为什么要使用DDD?DDD分为战略部分跟战术部分，相信大家都认同DDD的核心在战略而非战术。而战略方面的核心我认为在业务建模，领域划分、统一语言等都在为业务建模服务。为什么业务建模重要? 以前的开发流程有什么问题？先说结论，开发人员交付的程序对业务方，产品人员，测试人员来说就是一个黑盒子。除了开发人员自己，没人知道盒子里有什么。当新的需求加入来，需求方，产品人员，甚至测试人员都认为可行，开发人员却给出相反结论。回顾一下以前的开发流程大致可以归结为以下步骤：(开发跟测试人员最好能参与需求分析) 1.业
关联对象无法封装的数据库开销引入关联对象上下文过载因富含逻辑而产生的过大类逻辑汇聚于上下文还是实体通过角色对象分离不同上下文的逻辑通过上下文对象分离不同上下文的逻辑架构分层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的最爱。也是咨询类公司的最爱。这些玩意儿，有的可以忽悠大公司，有的可以忽悠小公司，反正谁也别想逃掉。但毒瘤如果
