《实现领域驱动设计》笔记(2)-第一章DDD入门

DDD入门

领域驱动设计作为一种软件方法，它可以帮助我们设计高质量的软件模型。在正确实现的情况下，我们通过DDD完成的设计恰恰就是软件的工作方式。

了解DDD可以为你的项目和团队带来哪些好处。

• 首先，DDD不应该是一个仪式性的过程，更不应该成为你项目进度的阻碍。我们的目标应该是创造一个可测试的，可伸缩，组织良好的软件模型。
• 将领域专家引入到团队是大有好处的
  在实施DDD的过程中，你最好将那些不怎么使用技术语言的人加进自己的团队。就像你会像他们学习一样，他们也会向你学习。
  但是我们还没有领域专家

领域专家并不是一个职位，他可以是精通业务的任何人。他们可能了解更多的关于业务领域的背景知识，他们可能是软件产品的设计者，甚至有可能是销售员。

什么是领域模型

领域模型是关于某个特定业务的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和型为，并且表达了准确的业务含义。

为什么我们需要DDD

• 1. 帮助业务人员自我提高
• 2.确保软件知识并不只是掌握在少数人手中。
• 3.领域/开发者，软件本身不存在“翻译”，当大家都是用相同的而语言进行交流，没人都能听懂他人所说。
• 4，设计就是代码，代码就是设计。

DDD如何帮助我们

• 1.领域专家和开发人员聚集到一起，开发的软件能够反映出专家的思维模型。
• 2.DDD关注业务战略
• 3.通过使用战术设计建模工具，DDD满足了软件真正的技术需求。

处理领域复杂性。

在使用DDD时，我们首先希望将他应用在最重要的业务场景下。这样的模型命名为核心域（Core Domain）,而相对次要的成为支撑子域（Supporting Subdomain）
DDD的作用是简化，而不是复杂化。
在使用DDD时，我们应该采用最简单的方式对复杂领域进行建模，而不是使问题变的更复杂。

贫血症和失忆症

贫血领域对象（Anemic Domain Object）表述一个缺少内在型为的领域对象。

如：

public bool SaveCustomer(参数1，参数2){
属性赋值，
Save();
}

三大问题：
1.业务意图不明显
2.方法的实现本身增加了潜在的复杂性
3.Customer本身并不是对象，而只是一个数据持有器。
这种情况成为“由贫血导致的失忆症”

如何DDD

DDD最具威力的特性：通用语言和限界上下文（Bounded Context）,同时构成了DDD的两大支柱，并且他们时相辅相成的。
通用语言，澄清的几点

是通用，不是万能。
只有团队工作在一个独立的限界上下文时，通用语言才是"通用“的。通过上下文映射图和其他限界上下文进行集成。每个限界上下文都有自己的通用语言。
如果你打算将某个通用语言运用在整个企业范围之内，你将失败。

DDD业务价值

• 1.获得了一个非常有用的领域莫能行
• 2.业务得到了更准确的定义和理解
• 3.领域专家可以为软件设计做出贡献
• 4.更好的用户体验。
• 5.敏捷/迭代式和持续建模
• 。。。
• 8.使用战略和站术新工具

实施DDD所面临的挑战

• 1.为创建通用语言腾出时间和精力
• 2.持续的将领域专家引入项目
• 3.改变开发者对领域的思考方式。
• 如何在项目中引入领域专家
  例子1：以数据为中心

public 类A{
    public 属性A1,
    public 属性B1
}

例子2：使用领域对象。

 pulic 类B{
     public 方法行为 （类C）{
     }
}

DDD并不笨重。

DDD能很好的与敏捷项目框架结合起来，也倾向于”测试先行，逐步改进“。
DDD-Lite是DDD站术模式的一个子集，它并不强调对通用语言的使用，此外，DDD-Lite通常也忽略了限界上下文和上下文映射图。