1.实现领域驱动设计 --- DDD入门

第1章 DDD入门
	即使软件中没有bug，也不能表示我们设计的软件模型本身就是好的。我们需要设计出能够准确表达业务意图的软件模型。


	我能DDD吗？
		将领域专家引入团队是大有好处的。领域专家并不是一个职位，他可以是精通业务的人。

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

	为什么我们需要DDD
		1.领域专家和开发者一起工作，这样开发出来的软件能够准确的传达业务规则。
		2.关键在于对知识的集中，因为这样可以确保软件知识并不只是掌握在少数人手中。
		3.在领域专家、开发者和软件本身之间不存在"翻译"，意思是当大家都使用相同的语言进行时，每个人都能听懂他人所说。
		4.设计就是代码，代码就是设计。
		5.DDD同时提供了战略设计和战术设计2种方式。战略设计帮助我们理解哪些投入是最重要的；哪些既有软件资产是可以重新拿来使用的；
		哪些人应该被加到团队中？战术设计则帮助我们创建DDD模型中各个部件。


		1.难以捉摸的业务价值：
			团队面临的问题：如何确定某种需求确实能够传递真正的业务价值？还有，我们如何去发现并暴露出这些业务价值，如何安排它们之间的
		优先级?并且实现它们？

			在开发过程中，最大的鸿沟之一便是存在于领域专家和开发者之间。通常来说，领域专家将关注点放在交付业务价值上，而开发者则将
		注意力放在技术实现上。这时开发软件边产生了一种映射：将业务人员所想的映射到开发者所理解的。这样一来，软件便不能完全反映出领域
		专家的思维模型。


		2.DDD如何帮助我们
			DDD作为软件开发方法，它主要关注以下3个方面：
				a)DDD将领域专家和开发人员聚集在一起，这样所开发的软件能够反映出领域专家的思维模型。这并不意味着我们将所有精力都花在了
				对"真实世界"的建模上，而是交付最具业务价值的软件。

				  领域专家和开发人员一起创建一套适用于领域建模的通用语言。通用语言必须在全队范围之内达成一致；所有成员都使用通用语言
				进行交流，通用语言也是对软件模型的直接反映。

				b)DDD关注业务战略。虽然说战略设计自然的包含了战术设计，但是战略设计关注更多的是业务的战略方向。它帮助我们定义不同团队
				之间的组织关系，并在这些关系有可能导致项目失败的时候提供早期预警。DDD的战略设计用于清楚的界分不同的系统和业务关注点，
				这样可以保护每个业务层面的服务。更进一步，这将指导我们如何实现面向服务架构和业务驱动架构。

				c)通过使用战术设计建模工具，DDD满足了软件真正的技术需求。这些战术设计工具使开发人员能够按照领域专家的思维模型开发软件。
				同时，所开发出来的软件是可测试的，能够尽量避免错误，能够执行服务层面的协议(SLA)，具有很好的伸缩性，并且允许分布式计算。
				DDD的最佳实践同时包含了高层的架构性实践和底层设计实践，关注业务规则和数据不变性，并且可以对业务规则起到保护作用。


		3.处理领域复杂性
			在使用DDD的时候，我们首先希望将它应用在最重要的业务场景下。对于那些可以轻易替换的软件来说，你是不会有所投入的。正因为如此，
		我们将这样的模型成为 核心域(Core Domain)，而那些相对次要的成为 支撑子域(Supporting Subdomain)。

			DDD计分卡：
				如果你的项目在某行的描述范围之内，那么请在右边的列上记上相应的分数，最后将这些分数相加得到总分。如果得分在7或者以上，
			那么，你应该考虑使用DDD了。


		4.贫血症和失忆症
			贫血领域对象，描述的是一个缺少内在行为的领域对象。

			病历卡：
				1.你的领域对象中是不是主要是些公有的getter和setter方法，并且几乎没有业务逻辑，或者甚至完全没有业务逻辑---对象嘛，
				主要用来容纳属性值的。
				2.软件组件经常使用的领域对象是否包含了系统主要的业务逻辑，并且多数情况下你需要调用那些getter和setter？你可能会将
				这样的客户代码称为服务层或者应用层代码。也或者，如果这描述的是你的用户界面，请回答"Yes"，然后好好反省下自己，告诫
				自己 一定不要再这么做了。

			如果你对以上两个问题的回到都是"No"，表明你的对象是健康的。如果都是"Yes"，表明你的领域对象已经病得不轻，这便是贫血对象。


		5.为什么会有贫血领域对象
			有贫血症导致的失忆症。在实施DDD的时候，设计就是代码，代码就是设计。


	如何DDD
		通用语言和限界上下文 同时构成了DDD的两大支柱，并且它们是相辅相成的。


		上下文术语：
			就现在来说，可以将限界上下文看成整个应用程序之内的一个概念性边界。这个边界之内的每种领域术语、词组或者句子---也即通用语言，
		都有确定的上下文含义。在边界之外，这些术语可能表示不同的意思。


		1.通用语言
			通用语言是团队共享的语言、领域专家和开发者使用相同的通用语言进行交流。通用语言是团队自己创建的公用语言，团队中同时包含
		领域专家和软件开发人员。

			你应该如何掌握通用语言呢？这里有一些实验性的方法：
				1.同时绘制物理模型图和概念模型图，并标以名字和行为；
				2.创建一个包含简单定义的术语表；
				3.如果不喜欢术语表，可以采用其他类型的文档，但记得将那些不正式的模型图也包含进去；
				4.由于团队中有些人工作在术语表上，有些人工作在文档上，此时你需要找到团队的其他人员来检查你的成果。

			另外，对领域模型的修改也将导致对应用层的修改。每一个应用层的方法都对应着一个单一的用例流。

			我们使用通用语言来捕捉特定核心业务领域中的概念和术语，它是一种团队模式。软件模型包含名词、形容词、动词和一些富有含义
		的语句等，团队成员便通