简介

精彩点评

• 

  lee

  推荐

  DDD个人觉得之所以这些年比较火、是因为他所倡导的思想、比如开发 测试 产品能形成一套共用的通用语言、方便交流，其次便是根据对业务的理解和预见划分合适领域、进行领域建模。关于本书 有很多新概念 我之前不太明白 现在是有些明白 还没有完全理解透彻、当然进行ddd的过程用事件驱动还是rpc还是rest 个人认为需要结合实际业务场景去设计 主要还是在领域模型的建立 怎么让你的服务代码可扩展性更好 从而来追求伸缩性和高可用 值得认真阅读 同时也配有案例

• 

  风中散发

  推荐

  基本搞懂领域驱动设计的思想了。领域，实体，值对象，上下文映射，聚合，领域服务。感觉这就是软件工程里开发方法中的面向对象设计方法的一种。

• 

  菜狗

  推荐

  ddd随着微服务开始兴起，但是概念略显抽象。这本书用实际案例较为通俗的解释了什么是ddd, 但是总的来说，这本书毕竟是多年前撰写，一些东西已经过时或者有了更好的解释。 总的来说，ddd不是灵丹妙药，而是一种指导思想。基于此，该书还是很有参考价值的，最重要的还是学会使用ddd结合自身业务，慢慢摸索。

• 

  max

  推荐

  书是一本很好的书，但翻译真的是一言难尽，说是机翻一点也不过分，简简单单的一句话，乱七八糟的组装到一起，理解起来反而变得困难了。比如：“唯一的身份标识和可变性（mutability）特征将实体对象和值对象区分开来。”，稍微整理一下句子就不会理解起来那么别扭。不是一句，是整本都是如此，读起来真的难受。

• 

  学彬

  推荐

  非常好的一本书，理论与实践结合，很好的阐述了3D设计的概念。用通俗的语言，概括明晰了领域设计的准则，对自己之前开发的经验是一个很好的升华。

• 

  郑同学

  推荐

  DDD（Domain-Driven Design 领域驱动设计） 由Eric Evans最先提出，目的是对软件所涉及到的领域进行建模，以应对系统规模过大时引起的软件复杂性的问题。 整个过程大概是这样的，开发团队和领域专家一起通过通用语言(Ubiquitous Language)去理解和消化领域知识，从领域知识中提取和划分为一个一个的子领域（核心子域，通用子域，支撑子域），并在子领域上建立模型，再重复以上步骤，这样周而复始，构建出一套符合当前领域的模型。 术语与基本概念 讨论完宏观概念以后，让我们来认识一下 DDD 的一些名词的概念。 统一语言 定义上下文的含义。它的价值是可以解决交流障碍，不管你是 RD、PM、QA 等什么角色，让每个团队使用统一的语言（概念）来交流，甚至可读性更好的代码。 通用语言包含属于和用例场景，并且能直接反应在代码中。 可以在事件风暴（开会）中来统一语言，甚至是中英文的映射、业务与代码模型的映射等。可以使用一个表格来记录。 限界上下文 定义上下文的边界。 领域模型存在边界之内。对于同一个概念，不同上下文会有不同的理解，比如商品，在销售阶段叫商品，在运输阶段就叫货品。 首先我们在描述领域时，必定会提到“限界上下文”,简单理解就是领域所处的环境以及邻域处理问题的边界。 理论上，限界上下文的边界就是微服务的边界，因此，理解限界上下文在设计中非常重要。 领域 领域就是范围。范围的重点是边界。 领域的核心思想是将问题逐级细分来减低业务和系统的复杂度，这也是 DDD 讨论的核心。 领域既可以表示整个业务系统，也可以表示某个核心子域或者支持子域。 可以简单的理解为一个比较完整的含有自己属性和行为的大对象（虽然不恰当，但是辅助理解吧）。 在微服务体系中可以理解为一个微服务（我们微服务拆分，通常也是以领域为概念来拆分的，他们两个可以相互理解）。 子域 领域可以进一步划分成子领域，即子域。这是处理高度复杂领域的设计思想，它试图分离技术实现的复杂性。这个拆分的里面在很多架构里都有。 核心域 在领域划分过程中，会不断划分子域，子域按重要程度会被划分成三类：核心域、通用域、支撑域。 决定产品核心竞争力的子域就是核心域，是业务成功的主要促成因素，没有太多个性化诉求。 桃树的例子，有根、茎、叶、花、果、种子等六个子域，不同人理解的核心域不同，比如在果园里，核心域就是果是核心域，在公园里，核心域则是花。 有时为了核心域的营养供应，还会剪掉通用域和支撑域（茎、叶等）。 通用域： 如果一个子域被应用于整个业务系统，被多个子域使用的通用功能就是通用域，没有太多企业特征，比如权限认证。 支撑域 对应着业务的某些重要方面，但不是核心，对于功能来讲是必须存在的，但它不对产品核心竞争力产生影响，也不包含通用功能，有企业特征，不具有通用性，比如数据代码类的数字字典系统。 聚合 聚合概念类似于你理解的包的概念，每个包里包含一类实体或者行为，它有助于分散系统复杂性，也是一种高层次的抽象，可以简化对领域模型的理解。 拆分的实体不能都放在一个服务里，这就涉及到了拆分，那么有拆分就有聚合。聚合是为了保证领域内对象之间的一致性问题。 在定义聚合的时候，应该遵守不变形约束法则： 聚合边界内必须具有哪些信息，如果没有这些信息就不能称为一个有效的聚合； 聚合内的某些对象的状态必须满足某个业务规则： 一个聚合只有一个聚合根，聚合根是可以独立存在的，聚合中其他实体或值对象依赖与聚合根。 只有聚合根才能被外部访问到，聚合根维护聚合的内部一致性。 聚合根 一个上下文内可能包含多个聚合，每个聚合都有一个根实体，叫做聚合根，一个聚合只有一个聚合根。 实体 Domain 或 entity。《领域驱动设计模式、原理与实践》一书中讲到，实体是具有身份和连贯性的领域概念，可以看出，实体其实也是一种特殊的领域，这里我们需要注意两点：唯一标示（身份）、连续性。 两者缺一不可。 你可以想象，文章可以是实体，作者也可以是，因为它们有 id 作为唯一标示。 值对象 为了更好地展示领域模型之间的关系，制定的一个对象，本质上也是一种实体，但相对实体而言，它没有状态和身份标识，它存在的目的就是为了表示一个值，通常使用值对象来传达数量的形式来表示。 比如 money，让它具有 id 显然是不合理的，你也不可能通过 id 查询一个 money。定义值对象要依照具体场景的区分来看，你甚至可以把 Article 中的 Author 当成一个值对象，但一定要清楚，Author 独立存在的时候是实体，或者要拿 Author 做复杂的业务逻辑，那么 Author 也会升级为聚合根。 还有一些概念，例如:上下文映射图、CQRS、领域服务、领域事件、模块、工厂、资源库、集成限界上下文等，还需要继续消化。