烂翻译系列之学习领域驱动设计——绪论

Introduction

绪论

Software engineering is hard. To be successful at it, we have to learn continuously, whether it’s trying new languages, exploring new technologies, or keeping up with new popular frameworks. However, learning a new JavaScript framework every week is not the hardest aspect of our job. Making sense of new business domains can be far more challenging.

软件工程很难。要想在这方面取得成功，我们必须不断学习，无论是尝试新的语言、探索新的技术，还是跟上新的流行框架。然而，每周学习一个新的 JavaScript 框架并不是我们工作中最困难的部分。理解新的业务领域可能更具挑战性。

Throughout our careers, it’s not uncommon for us to have to develop software for a diverse range of business domains: financial systems, medical software, online retailers, marketing, and many others. In a sense, that is what differentiates our job from most other professions. People working in other fields are often surprised when they find out how much learning is involved in software engineering, especially when changing workplaces.

纵观我们的职业生涯，我们常常不得不为各种各样的业务领域开发软件: 金融系统、医疗软件、线上商城、市场营销和许多其他领域。在某种意义上，这就是我们的工作区别于大多数其他职业的地方。在其他领域工作的人员，当他们发现软件工程中要花费多少学习成本时，他们往往会感到惊讶，尤其在换工作的时候。

Failure to grasp the business domain results in suboptimal implementation of the business software. Unfortunately, that’s quite common. According to studies, approximately 70% of software projects are not delivered on time, on budget, or according to the client’s requirements. In other words, the vast majority of software projects fail. This issue is so deep and widespread that we even have a term for it: software crisis.

未能掌握业务领域的结果是业务软件的实现不够理想。不幸的是，这很常见。根据研究，大约70% 的软件项目没有按时、按预算或根据客户的要求交付。换句话说，绝大多数的软件项目都会失败。这个问题是如此深刻和广泛，我们甚至用一个专业术语来描述它: 软件危机。

The term software crisis was introduced all the way back in 1968. One would assume that things would have improved in the intervening 50 years. During those years, numerous approaches, methodologies, and disciplines were introduced to make software engineering more effective: Agile Manifesto, extreme programming, test-driven development, high-level languages, DevOps, and others. Unfortunately, things didn’t change much. Projects are still failing quite often and the software crisis is still here.

术语“软件危机”早在1968年就被提出来了。人们可能会认为，在此后的50年里，情况会有所改善。在这些年里，为了使软件工程更加有效，引入了许多方法、方法学和规程: 敏捷宣言、极限编程、测试驱动开发、高级语言、 DevOps 等等。不幸的是，事情并没有太大的改变，项目仍然经常失败，软件危机仍然存在。

Many studies have been conducted to investigate the reasons for the common project failures. Although researchers have not been able to pinpoint a single cause, most of their findings share a common theme: communication. Communication issues thwarting projects can manifest themselves in different ways; for example, unclear requirements, uncertain 1 2 project goals, or ineffective coordination of effort between teams. Yet again, over the years, we have tried to improve inter- and intrateam communication by introducing new communication opportunities, processes, and mediums. Unfortunately, the success rates of our projects still didn’t change much.

人们对常见项目失败的原因进行了大量的研究调查。尽管研究人员还不能确定一个单一的原因，但他们的大多数发现都有一个共同的主题: 沟通。阻碍项目的沟通问题可以由不同的方式体现出来；例如，不明确的需求，不确定的项目目标，或者团队之间工作的无效协调。多年来，我们一直尝试通过引入新的沟通因素、流程和方法来改善团队内部和团队之间的沟通。不幸的是，我们项目的成功率仍然没有太大的变化。

Domain-driven design (DDD) proposes to attack the root cause for failed software projects from a different angle. Effective communication is the central theme of the domain-driven design tools and practices you are about to learn in this book. DDD can be divided into two parts: strategic and tactical.

领域驱动设计(DDD)建议从不同的角度解决软件项目失败的根本原因。有效的沟通是领域驱动设计工具和实践（你将在本书中学习的知识）的中心主题。DDD 可以分为两个部分: 战略和战术。

The strategic tools of DDD are used to analyze business domains and strategy, and to foster a shared understanding of the business between the different stakeholders. We will also use this knowledge of the business domain to drive high-level design decisions: decomposing systems into components and defining their integration patterns.

DDD 的战略工具用于分析业务领域和战略，并促进不同利益相关者之间对业务的共同理解。我们还将使用业务领域的这些知识来驱动高级设计决策: 将系统分解为部件并定义它们的集成模式。

Domain-driven design’s tactical tools address a different aspect of communication issues. DDD’s tactical patterns allow us to write code in a way that reflects the business domain, addresses its goals, and speaks the language of the business.

领域驱动设计的战术工具解决了沟通问题的不同方面。DDD 的战术模式允许我们以反映业务领域、解决其目标和使用业务语言的方式编写代码。

Both the strategic and tactical patterns and practices of DDD align software design with its business domain. That’s where the name comes from: (business) domain-driven (software) design.

DDD 的战略和战术模式及实践都使软件设计与其业务领域保持一致。这就是这个名字的由来: (业务)领域驱动(软件)设计。

Domain-driven design won’t make it possible to install the knowledge of new JavaScript libraries directly into your brain, like in The Matrix. However, it will make you a more effective software engineer by alleviating the process of making sense of business domains and guiding the design decisions according to the business strategy. As you will learn in the book’s later chapters, the tighter the connection between the software design and its business strategy is, the easier it will be to maintain and evolve the system to meet the future needs of the business, ultimately leading to more successful software projects.

领域驱动设计不能像《黑客帝国》里那样，让你直接把新的 JavaScript 库的知识装到你的大脑中。然而，它将使您成为一个更优秀的软件工程师，因为它减轻了理解业务领域的痛苦过程，并根据业务战略指导设计决策。正如您将在本书后面的章节中学到的，软件设计与其业务策略之间的联系越紧密，就越容易维护和演化系统以满足业务的未来需求，最终引导更成功的软件项目。

Let’s start our DDD journey by exploring the strategic patterns and practices.

让我们通过探索战略模式和实践来开始我们的 DDD 之旅。