领域驱动设计

领域设计随着微服务的越来越火，领域设计也越来越火。

什么是领域设计？

一、了解领域设计，如何通过模型来吸收知识

      一些设计因素是技术上的。大批开发人员很注意培养自己的技能，并紧跟每一次技术进步。很多的应用程序主要的复杂性不在于技术上，而来自于领域本身、用户的活动或者业务。

领域设计注重领域模型的建立。模型：用来描绘人们所关注的现实或想法的某个方面，模型是一种简化。它是对现实的解释-把与解决问题密切相关的方面抽象出来，而忽略无关的细节。领域：每个软件程序是为了执行用户的某项活动，或是满足用户的某种需求。这些用户应用软件的问题区域就是软件的领域。

领域建模做的是什么？

1. 开发人员要开发软件必须要了解对方业务的知识体系，但是这个知识的广度是很巨大的，非常消耗人力的。那么模型就可以解决此类信息超载问题的工具。模型对知识的形式对知识进行了选择性的简化和有意的结构化。适当的模型可以使人理解信息的意义，并专注于问题。

2.并不是某种特殊的图或者说工具，而是传达的一种思想。不单单是领域专家头脑中的知识，而是对这类知识严格的组织且有选择的抽象。

3.并不是要建立一个符合或者说接近现实的一个模型。更加像是电影一样来源于现实、但是高于现实。有更高的思想来反映更多的现实现象。这种抽象的思想就是我们最终达到的目的。

建模作用是什么？

1.模型和设计的核心相互影响。正是模型和实现之间的紧密联系才使得模型更加有用，并确保我们在模型中进行的分析最终转化为最终的产品。

2.模型是团队所有成员使用通用语言的中枢。模型和实现之间的关联，开发人员可以使用语言来讨论程序。

3.模型是浓缩的知识。模型是团队一致认同的领域知识的组织方式和重要元素的区分方式。透过我们如何选择术语、分解概念以及将概念联系起来，模型记录了我们看待领域的方式。

拿到项目如何进行领域分析建模？

1.领域模型建立个人技巧：

1.1可以通过双方经常用到的词汇作为导线进行知识体系构建。

1.2 可以通过流程化的进行体系构建，这种方法通常会陷入细节中失去核心目的，导致模型不停的修改。主要是边界不明确、抽象程度不够高等问题带来的影响。但可以了解流程。

1.3 模型和现实的强耦合，可以通过画图来描述问题或流程。

1.4 建立一种基于模型的语言，这个主要是有利于双方的理解，可以用已有的工具如UML，当然也可以简单的画图。

1.5可以利用一些行为或者说是规则设计一个包含丰富知识的模型。

1.6 以一种带有目的的方式来提炼概念，将重要的概念提炼到模型中。

大概的轮廓的草图有了，然后进行一个知识消化，如何消化？

看一下分析员、业务员的知识是否能传输到模型中，所以模型的组织需要更加的严密，更加抽象，但是更加的整洁。好的代码抽象但是非常容易读（会分析）。查的代码无从下手。弄好之后从新整理模型进行合作打造反馈闭环。

在知识处理这一环节，通过设计可以达到什么结果呢？

比如有核心的业务规则，核心的业务流程。我们可以进行知识保护和知识共享。

 二、模型语言

       领域设计主要流程就是交流定设计，交流就需要共同的语言。UML是共同语言中的一种。语言如果如果支离破碎，项目必定会遇到问题。语言不一致会导致对领域深刻表述常常梢纵即逝，根本无法记录到文档中。

将模型作为语言的支柱。确保团队在内部的所有交流中以及代码中坚持使用这种语言。在画图、写东西，特别是讲话时也要使用这种语言。通过尝试不同的表示方法来消除难点。然后重构代码，重新命名类、方法和模块，以便与新模型保持一致。领域专家应该抵制不合适或无法充分表达领域理解的术语和结构，开发人员应该密切关注哪些将会妨碍设计的有歧义和不一致的地方。

    图是一种沟通和解释的手段，它们可以促进头脑风暴。图讲究简洁，因为简洁的图可以很好的实现这些目标，而对象模型的综合性大图失去了沟通和解释的能力，缺乏目的性。图不是模型，图的目的只是帮助表达和解释模型。当然图也不能表示全部模型和设计。

    有时候不能僵硬的采用类图这种固定的套路来表示，而应该画图来表示，图能够很接近的反应一个运作。

三、模型绑定实现

       如果整个程序设计或者其核心部分没有与领域模型相对应，那么这个模型就是没有价值的，软件的正确性就值得怀疑。同时模型和设计功能之间过于复杂的对应关系也是难以理解的，在实际项目中，当设计改变时也无法维持这种关系。 若分析与设计之间产生的严重分歧，那么在分析和设计活动中所获得的知识就无法彼此共享。分析工作一定要抓住领域内的基础概念，并且用易于理解和易于表达的方式描述出来。

1.!!!!!过程语言和面向对象设计上区别？

 面向对象能实现的过程性语言也能实现，设计程序有什么区别呢？

过程性语言支持复杂的数据类型，虽然能对应到领域的概念上，但是只是被组织到一起的数据，而不是通过概念关联到一起的。

概念是什么？如何通过概念方式来解析源码？！！！！重点来了：

案例1：spark中很多作业状态，task状态,stage状态等需要处理。这个多的事件如何设计和管理呢？

我们可以借鉴操作系统的思想来思考这个问题：设计一个事件总线

然后各个分支将有效的监听到的事件推到总线上。

Spark离线总线对应的类SparkListenerBus，实时对应的类StreamingListenerBus。总线在操作系统中都是有收和发的，当然spark的设计中也是有对应的设计的LiveListenerBus和ReplayListenerBus继承Spark离线的类。

问题是如何启动这个让他不停的监听？如何推送到总线？如何启动？

如果你是这个思考路线说明是线性思考而不是领域模型的思考。那什么叫做领域模型的思考？

领域模型思考应该是领域核心目的是什么？领域边界是什么？

这个例子的领域核心是监听，领域边界就是所有的处理结果。只要涉及到处理的。

领域概念性对象呢？如何寻找？

1.本人习惯：一定是名词，有名词才有动作。动作可以为被动和主动。

这个模型中概念主要为三大类：上下文、事件、监听。

有了概念对象就要分析什么呢？动作

上下文用来启动监听，关闭监听。事件产生，事件提交。监听消息

有了动作时候呢？泛化

监听消息，消息多种多样，如何让事件这种变化的去适应消息呢？我们可以采用适配器的方式。适配器模式？

记住设计模式只是一种模式而不是固定的写法，这个模式的核心思想是你中有我，我中有你。这种是适合做多对一场景，不适合做多对多的场景。那什么场景是扔进去对象出来相对应的对象呢？工厂模式。这种模式通常被用来产生多对多对象的。对应类：SparkListenerBus，SparkListenerEvent，SparkListenerInterface，LiveListenerBus

事件产生，不同的job，或者task，stage对应了不同的事件，这些事件如何管理？

需要定义不同的事件，列出每个事件的属性，值等吗？不需要，变化的属性抽离掉。提供它一个壳，让job或者task或者stage来填充， 这个壳有型无体。SparkListenerEvent

事件如何提交呢？

事件通常需要提交到队列中，然后队列去循环取。

最后一个上下文。上下文，通常而言一个上线文中的一个管理器启动就是一个模型。

好了，源码讲解完了，详细链接：

https://blog.csdn.net/u014733604/article/details/86670752

这种设计前提一定是边界清楚，领域清晰。

思考设计的时候模型分类有：分析模型、设计模型、用户模型和设计/实现模型。

分析模型：

面向对象分析，通常有功能模型（用例分析）、对象模型（类图表示类之间关系）、动态模型（时序图和协作图之间关系）。

设计模型是对面向对象分析的细化。