DDD入门
领域驱动设计作为一种软件方法，它可以帮助我们设计高质量的软件模型。在正确实现的情况下，我们通过DDD完成的设计恰恰就是软件的工作方式。
了解DDD可以为你的项目和团队带来哪些好处。
- 首先，DDD不应该是一个仪式性的过程，更不应该成为你项目进度的阻碍。我们的目标应该是创造一个可测试的，可伸缩，组织良好的软件模型。
- 将领域专家引入到团队是大有好处的
在实施DDD的过程中，你最好将那些不怎么使用技术语言的人加进自己的团队。就像你会像他们学习一样，他们也会向你学习。
但是我们还没有领域专家
领域专家并不是一个职位，他可以是精通业务的任何人。他们可能了解更多的关于业务领域的背景知识，他们可能是软件产品的设计者，甚至有可能是销售员。
什么是领域模型
领域模型是关于某个特定业务的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和型为，并且表达了准确的业务含义。
为什么我们需要DDD
- 帮助业务人员自我提高
- 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通常也忽略了限界上下文和上下文映射图。
