标签：努力 导致 软件 事物 自己的 目录 建模 理解 运用
模型被用来描绘人们所关注的现实或想法的某个方面。模型是一种简化。是对现实的解释——把与解决问题密切相关的方面抽象出来，而忽略无关的细节。
每个软件程序是为了执行用户的某项活动，或是满足用户的某种需求。这些用户应用软件的问题区域就是软件的领域。一些领域涉及物质世界，例如，机票预订程序的领域中包括飞机乘客在内。有些领域则是无形的，例如，会计程序的金融领域。软件领域一般与计算机关系不大，当然也有例外，例如，源代码控制系统的领域就是软件开发本身。
（技术或者软件是用来实现业务所要的功能或者解决业务计算遇到的瓶颈）
为了创建真正能为用户活动所用的软件，开发团队必须运用一整套与这些活动有关的知识体系。所需知识的广度可能令人望而生畏，庞大而复杂的信息也可能超乎想象。模型正是解决此类信息超载问题的工具。模型这种知识形式对知识进行了选择性的简化和有意的结构化。适当的模型可以使人理解信息的意义，并专注于问题。
（个人理解：如果遇到要对一个庞大复杂的业务做系统开发，所需要的知识体系非常大，这个时候可以使用一些抽象的模型或者方法，更好的理清业务逻辑，形成软件系统，有些人为什么业务设计能力那么厉害，就是因为抽象思维能力很强）
领域模型并非某种特殊的图，而是这种图所要传达的思想。它绝不单单是领域专家头脑中的知识，而是对这类知识严格的组织且有选择的抽象。图可以表示和传达一种模型，同样，精心书写的代码或文字也能达到同样的目的。领域建模并不是要尽可能建立一个符合“现实”的模型。即使是对具体、真实世界中的事物进行建模，所得到的模型也不过是对事物的一种模拟。它也不单单是为了实现某种目的而构造出来的软件机制。建模更像是制作电影——出于某种目的而概括地反映现实。即使是一部纪录片也不会原封不动地展现真实生活。就如同电影制片人讲述故事或阐明观点时，他们会选择素材，并以一种特殊方式将它们呈现给观众，领域建模人员也会依据模型的作用来选择具体的模型。
在领域驱动的设计中，3个基本用途决定了模型的选择。
(1) 模型和设计的核心互相影响。正是模型与实现之间的紧密联系才使模型变得有用，并确保我们在模型中所进行的分析能够转化为最终产品（即一个可运行的程序）。模型与实现之间的这种紧密结合在维护和后续开发期间也会很有用，因为我们可以基于对模型的理解来解释代码。
(2) 模型是团队所有成员使用的通用语言的中枢。由于模型与实现之间的关联，开发人员可以使用该语言来讨论程序。他们可以在无需翻译的情况下与领域专家进行沟通。而且，由于该语言是基于模型的，因此我们可借助自然语言对模型本身进行精化。
(3) 模型是浓缩的知识。模型是团队一致认同的领域知识的组织方式和重要元素的区分方式。透过我们如何选择术语、分解概念以及将概念联系起来，模型记录了我们看待领域的方式。当开发人员和领域专家在将信息组织为模型时，这一共同的语言（模型）能够促使他们高效地协作。模型与实现之间的紧密结合使来自软件早期版本的经验可以作为反馈应用到建模过程中。
软件的核心是其为用户解决领域相关的问题的能力。所有其他特性，不管有多么重要，都要服务于这个基本目的。当领域很复杂时，这是一项艰巨的任务，要求高水平技术人员的共同努力。开发人员必须钻研领域以获取业务知识。他们必须磨砺其建模技巧，并精通领域设计。
（个人理解：然而，很多技术开发人员都不会主动去了解业务设计，只关注自己的技术是否得到提高，我曾经的组员很多都是这样的思维，最后导致做东西需要别人来设计框架，讲解逻辑，自己使用技术实现，非常片面的认为写代码是技术的全部，认为掌握很多复杂的业务新知识，而这些新知识对提高计算机的能力并无裨益。我认为，技术人员使用模型来抽象业务逻辑，是非常有必要的。）
开发人员可以采用一些系统性的思考方法来透彻地理解领域并开发出有效的模型。还有一些设计技巧可以使毫无头绪的软件应用变得井井有条。掌握这些技能可以令开发人员的价值倍增，即使是在一个最初不熟悉的领域中也是如此。
标签：努力 导致 软件 事物 自己的 目录 建模 理解 运用
原文地址：https://www.cnblogs.com/zhijiancanxue/p/12514549.html
