有关领域驱动设计的只言片语

在创建微服务的过程中，DDD可以在一下4个主要领域发挥作用：

战略设计： 这一阶段的主要工作就是界限上下文的设计，但上下文图（Context Map）与其他模式也同样十分重要。

内部构建块： 在设计一个界限上下文的内部结构时将用到DDD中的多种战术模式，例如，实体、聚合、repository

大比例结构：通过有序演化与职责层模式创建结构

精炼：通过精炼方法，从一个已经成熟的系统中提炼出一个核心领域

任何一个具有高复杂度的业务领域都由一个或多个界限上下文组成，每个上下文负责领域中的一部分内容。每个界限上下文都包含用于描述领域的模型，同时也定义了这些模型所代表的意义的边界。以一个客户对象为例，每个界限上下文都是按照独有的模型与视角来定义这个客户对象的。

上下文图描述了系统中的所有界限上下文，以及他们之间的相互关联及上下文之间的契约。

以下是界限上下文之间常见的关系模式：

共享内核模式（Shared Kernel） : 它表示两个上下文或模型之间共享某个领域的一个子集，包括代码在内。这种模式将增加系统的依赖。

客户 / 供应商模式（Customer / Supplier）: 某个上下文将扮演客户的角色，它将从另一个扮演供应商角色的上下文中请求特性。

防崩溃层（Anticorruption layer，ACL）: 某个客户端将利用转换器（translator），将其自身的模型与其他模型进行隔离。在将系统转型为微服务或自包含系统（Self-Contained，SCS）架构时，这是一种非常有趣的选择，ACL将表现为一个系统的护罩，以抵御来自外部的侵扰。

聚合是由多个领域对象构成的一个逻辑组，其中的对象将作为一个整体进行处理。聚合中的某个实体将成为聚合根，它负责接收所有外部请求，并负责整个聚合的生命周期。
对于僵硬的架构或是过于复杂的系统来说，可以选择创建一个跨界限上下文的大比例结构，让这个结构随着对于高层次概念的理解不断加深而逐渐进化。
职责层模式是另一种在界限上下文之内创建一个内部结构的结构模式，其思想是按照职责进行结构的创建，而微服务的结构也可以应用相同的概念进行设计。

基础设施层:在基础设施服务中解决交叉问题。

存储层: 数据访问及持久化技术层。

领域层:领域层有业务实体和业务逻辑，是应用程序的中心。

应用服务层: 提供对消费者的响应动作

Web层: 应用程序的消费者

Bounded Context创建的模型较小，而且内聚性更高，同时维持了模型之间的边界

What is the Core Domain?

The core domain is the part of the domain most closely associated with the strategy of the company.

Definition of Strategy

I offer the following definition for the strategy of a company:

Strategy refers to objectives as a function of environment and available resources, followed by the allocation of these resources, in order to create value for customers while simultaneously creating profit for the company and its employees.

A few remarks concerning this definition:

A well-defined strategy must outline the priorities around which employees concentrate their time and effort

Profit certainly means financial gain, but it also includes job satisfaction and career advancement for the employees, with similar benefits for the customers. “Don’t be evil,” as they say.

Strategy is dynamic; it is changing or will change over time because the environment is changing, and with it the objectives

What is a Support Domain?

A support domain is a part of the domain that indirectly supports the core domain without actually belonging to it.

Typically, this is a thing that everyone needs, yet no one wants to pay for. The reason is that the value added, taken in isolation, is weak. For example, bookkeeping is indispensable in many banking activities, but no one wants to pay for it.

What is a Generic Domain?

A generic domain is one that is universally well-known, without any need for specialization in the core domain.

Some classic examples are accounting, human resources, and project management. These domains are widely known, sometimes even including their various sub-fields. In technical terms, this could for instance be an optimization tool for finding a path in a graph (and many problems, I might add, can be boiled down to a graph). Options to consider here, naturally, would be open source, software packages, outsourced development, and, lastly, in-house development. In this latter case, it would be pertinent to ask the following questions: Is it worth my while to write the software? Why not purchase it off-the-shelf? Why not outsource it?