领域驱动介绍
什么是软件
软件是一种被创建用来帮助我们处理现代生活中复杂问题的工具，它不是终极目标，而是到达目的的一种方法。这个目的通常是非常实际和真实的事情，比如我们使用软件控制空中交通。这个例子说明了软件的直接联系和实际应用性。我们想从一个地方飞到另一个地方，需要通过使用复杂的机器达到目的，于是我们制造软件来协调那些在空中飞行的数以千计的飞机。因此，作为软件架构师，你需要理解软件的本质和作用，并且将这种理解贯穿于你的工作中，以确保你的软件能够达到实际应用的目的。
软件必须是实际和有用的，否则我们不会花那么多时间和资源去创建它。软件的实际应用性和有用性是与我们生活的某个方面密切相关的。一个有用的软件包不能和现实，也就是假定能帮助我们管理的领域，分割开来。相反，它们紧密相连。因此，作为软件架构师，你需要明确软件的实际应用性和有用性，并且将这种理解贯穿于你的工作中，以确保你的软件能够达到实际应用的目的。同时，你需要注重软件的整体架构和设计，以确保软件的可靠性、可扩展性、可维护性和安全性。这样，你的软件才能够真正地满足用户的需求，为用户提供价值。
与其他艺术一样，软件设计不能通过定理和公式以一门精确科学的方式被教授和学习。通过软件创建的过程，我们可以发现有用的规律和技巧，但是我们也许永远不能提供一个准确的方法，以满足从现实世界映射到代码模型的需要。因此，软件设计需要结合实践和经验，以及创造性和直觉。软件产品既包括设计和开发它的那些人的个人劳动，也包括致力于它发端和成长的那些人的某些领导力和洞察力（或者没有这个）。因此，作为软件架构师，你需要注重软件的整体设计和开发过程，同时也需要注重团队的领导力和协作能力，以确保软件能够达到高质量的标准，并且能够持续发展和成长。
领域驱动设计是什么？
领域驱动模型的方向
软件开发通常被应用到真实世界中已经存在的自动化流程，或者给真实的业务问题提供解决方案，即要自动化的业务流程或者可以用软件解决的现实问题。因此，软件开发需要深入了解所在的领域，才能够为业务问题提供更好的解决方案。从一开始，我们就必须明白软件脱胎于领域，并跟领域密切相关。只有了解领域中的业务流程和需求，才能够更好地设计和开发出符合实际需要的软件产品。
同时，你也需要注意到软件是由代码最终构成的，但是软件开发过程不仅仅是编写代码。有时候，我们会被代码所诱惑，在它上面花费了太多的时间，将软件看作是简单的对象或者方法。但是，软件开发涉及到的问题远不止代码。
实践案例
缺乏领域概念的执行层
假设以汽车制造来类比，参与汽车制造的工人会专门负责汽车的某个部件，但这样做的后果是工人们通常对整体的汽车制造流程缺乏了解。他们可能将汽车视为一大堆需要固定在一起的零件的集合体，但一辆汽车的意义远不只于此。
填充领域模型的设计层
一辆好车起源于一个好的创意，开始于认真制定的规格说明，然后再交付给设计。
经历若干道设计工序，用上几个月甚至几年的时间去设计、修改、精化直至完美，直至它反映出最初的愿景。
测试以及最后的落地
设计的过程也不全然是在纸上进行的，许多的设计工作包括制模、在极端条件下对它们进行测试，以验证它们是否能工作等。设计会根据测试的结果做出修改。
汽车最终被交付到生产线上，在那里，所有的部件已经就绪，然后被组装到一起。
领域知识存在的意义
软件开发也是一样。我们不能直接坐下来敲代码。当然也可以这样做，在开发价值不大的软件时。但我们不能用这种方法开发复杂的软件。
为了创建一个好软件，你必须知道这个软件究竟是什么。在你充分了解金融业务是什么之前，你是做不出一个好的银行业软件系统的，你必须理解银行业的领域。
丰富的领域知识对于复杂的银行业务软件开发至关重要。软件架构师、分析师或开发人员都不如银行的业务人员更了解银行业务系统，因为他们是银行业务系统的专家，知道所有的细节、困难、问题和规章等。在启动一个软件项目时，我们应该关注软件涉及的领域，因为软件的最终目的是增进特定领域，为了达到这个目的，软件需要与要服务的领域和谐相处，否则会给领域引入麻烦，产生障碍、灾难甚至导致混乱。
软件和领域的关系
为了让软件和领域和谐相处，最佳的方式是让软件成为领域的反射，即具现领域里重要的核心概念和元素，并精确实现它们之间的关系。因此，我们需要对领域进行建模。
对领域进行建模
建立领域的抽象是非常重要的，因为没有植根于领域的软件不能很好地应对变化。从领域开始着手，我们需要为领域建立一个抽象，在脑海中建立一个蓝图。
对领域建立蓝图
领域中的蓝图是一个模型，一个关于领域的模型。按照Eric Evans的观点，领域模型不是一幅具体的图，它是那幅图要极力去传达的那个思想。它也不是一个领域专家头脑中的知识，而是一个经过严格组织并进行选择性抽象的知识。
因此，我们需要通过与领域专家交流，学习领域知识，并将其转换成一个清晰的、抽象的模型。这个模型能够描绘和传达领域的本质，让软件能够更好地服务于领域。最终，通过精心编写的代码和一段英语句子，我们能够达到将模型转换成软件的目的。
领域模型
领域模型是对目标领域的内部展现方式，是设计和开发过程中非常必要的。
模型设计的重要性
模型是软件设计中最基础的部分，因为它能够帮助我们处理复杂问题。我们的所有领域思考都被汇总到这个模型中，但它必须超越我们的头脑，否则它就无法发挥作用。因此，我们需要与领域专家、资深的设计人员和开发人员进行交流，以确保模型的准确性和完整性。模型是软件的根本，但我们需要找到一些方法来表现它，让它能够与其他事物进行交流。在这个过程中，我们需要共享知识和信息，并不断改进模型，使其更加精确、完整、无二义性。有许多方式可以实现这一点，其中常见的一种方式是将模型图形化，例如使用图、用例、画和图片等。另一种方式是通过书写来表达我们对领域的愿景。还有一种方式是使用语言，我们可以为要交流的领域内的特定问题建立一种语言。在接下来的章节中，我们将详细讲解这些方法，但主要观点是我们需要用模型来交流。
领域模型的知识范围
在设计过程中，我们需要对模型的很多方面进行引用。然而，我们周围的世界中有着海量的内容等待我们去处理，甚至一个特定的领域所包含的内容都远远超出了人脑一次可以处理的范畴。
领域模型的系统化处理
需要组织信息，将其系统化，将其分割成小的信息块，并将这些信息块分类放到逻辑模块中。
在处理信息时，我们需要忽略领域中的很多部分，因为领域包含了如此之多的信息，不能一下子放到一个模型中。
保留和剔除内容范围
而且，我们也不必考虑其中的很多部分。这对于模型本身也是一个挑战：要保留哪些内容，放弃哪些内容呢？这在软件建立过程中属于设计部分的范畴。
优化领域模型
例如，银行业软件需要跟踪客户的住址，但不需要关心客户的眼睛是什么颜色的。这是一个很明显的例子，但其他的例子可能不会如此明显。因此，在设计和开发过程中，我们需要不断地审查和完善模型，以确保其准确反映领域的本质，从而让软件能够更好地服务于领域。
面向人群
无论你是企业架构师、团队领导者、项目经理还是高级软件开发人员，本文章都可以帮助你正确理解领域驱动设计，并同时实现你的业务目标和技术目标。
重点决策人群：团队领导者、技术架构师、项目经理和业务架构师。
主题方向
Java、.NET、SOA、Agile、Ruby 和 Architecture。
推荐学习
《领域驱动设计——软件核心复杂性应对之道》（Addison-Wesley 2004，已由清华大学出版社翻译出版）。
领域驱动设计——软件核心复杂性应对之道
它提供了一个建模和设计技术的系统，成功的团队应用这一系统可以组装有业务需求的复杂软件系统，并使系统在增大时仍然保持敏捷。
Domain Language 是一个咨询小组，它指导和训练团队实施领域驱动设计，帮助他们使自己的开发工作对业务而言更有生产力和更有价值。
领域驱动设计建议
- 亲力亲为，模型需要代码支持。
- 专注于具体场景，将抽象思维应用到具体案例中。
- 不要试图对所有事情都进行领域驱动设计。可以画一张范围表，然后决定哪些应该进行领域驱动设计，哪些不需要。不必担心边界之外的事情。
- 不断进行实验，期望能够发现错误。模型的创造过程需要不断尝试和改进。
