【读书笔记】【设计】实现领域驱动设计(DDD)笔记([reading notes] [design] implement Domain Driven Design (DDD) notes)

前言:

  领域驱动设计,是一种架构思想,它不是关于技术的,而是关于讨论、聆听、发现和业务价值的,而这些都是为了把知识挖掘并表达出来。

  敏捷开发:DDD并非充满繁文缛节的笨重的开发过程,相反它可以和敏捷很好的结合。可以采用“测试先行、逐步改进”的设计思路。其中重构是最必要的一步。

领域:

  领域分类:可以划分为核心子域、支撑子域、通用子域。核心域是值得配置最好的开发者的,但是有时候子域在自己眼里也是自己的核心域。所以核心是相对而言的,相对整个BU来说,也会有自己赚钱的核心域。

  • 核心域拥有核心的知识抽象,使用DDD战术回大有裨益。不过DDD战术同样适用在其他域中。

  问题空间:问题空间是核心域和其他子域的组合。问题空间中的子域通常随着项目的不同而不同,他们各自关注于当前的业务。

  解决方案空间:解决方案空间包含一个或者多个界限上下文,所以说一个界限上下文对应的是一个解决方案,解决方案可以是演进的。

  界限上下文:界限上下文是一个显式的边界,领域模型便存在于这个边界当中,领域语言把通用模型表达为软件模型。每一个模型概念,包括它的属性和操作,在边界之内都具有特殊的含义。

  • 它对应了一组解决方案,一个会议可能会形成一个上下文,产生一个解决方案。
  • 好的设计应该是每一个子领域内应该形成自己的子域界限上下文的,不然的话可能你的子域可能划分的不太好。然后一个大领域下就会存在多个不同的界限上下文。——(P49)
  • 在一个好的界限上下文中,一个术语应该值表达一种领域概念,例如顾客在不同上下文中含义就不同,所以应该在不同上下文中让顾客更佳实体化,例如在会员系统中顾客就是:会员顾客
  • 上下文和物理结构不一定要是一一对应的

  上下文映射图:这些不同的上下文中的模型会有重叠的本质物理实体,但表现出了不同的领域模型。这个时候就需要为他们的映射关系进行管理,最有效的手段就是上下文映射图。

  通用语言:通常来说,通用语言和界限上下文存在一一对应的关系。

  战略重要性:战略设计基本会划分大大小小的各个子域及上下文,但是有些情况下一个新的子域或许不会那么明显,那么在知识沉淀的时候会发现矛盾所在,所以上下文也有可能新增和重整。这些都是会上升到战略层的决定。如果不重构矛盾到子域,可能会导致一些大泥球的设计。

————————

preface:

Domain driven design is an architectural idea. It is not about technology, but about discussion, listening, discovery and business value, which is to mine and express knowledge.

Agile Development: DDD is not a cumbersome development process full of red tape. On the contrary, it can be well combined with agile. The design idea of “test first and gradual improvement” can be adopted. Refactoring is the most necessary step.

Field:

Domain classification: it can be divided into core sub domain, support sub domain and general sub domain. The core domain is worth configuring the best developers, but sometimes the sub domain is also its own core domain in its own eyes. Therefore, the core is relatively speaking. Compared with the whole Bu, it will also have its own core domain to make money.

  • The core domain has the core knowledge abstraction, and the use of DDD tactics is of great benefit. However, DDD tactics also apply to other domains.

Problem space: problem space is a combination of core domain and other sub domains. The sub domains in the problem space usually vary with different projects, and they focus on the current business.

Solution space: solution space contains one or more boundary contexts, so a boundary context corresponds to a solution, and the solution can be evolutionary.

Boundary context: the boundary context is an explicit boundary in which the domain model exists. The domain language expresses the general model as a software model. Every model concept, including its attributes and operations, has a special meaning within the boundary.

  • It corresponds to a set of solutions. A meeting may form a context and produce a solution.
  • Good design should form its own sub domain boundary context in each sub domain, otherwise your sub domain may not be well divided. Then there will be many different boundary contexts in a large field—— (P49)
  • In a good boundary context, a term should value to express a domain concept. For example, customers have different meanings in different contexts, so customers should be better materialized in different contexts. For example, in the member system, customers are: member customers
  • Context and physical structure do not have to correspond one-to-one

Context map: these models in different contexts will have overlapping essential physical entities, but show different domain models. At this time, it is necessary to manage their mapping relationship. The most effective means is context mapping.

General language: Generally speaking, there is a one-to-one correspondence between general language and boundary context.

Strategic importance: strategic design will basically divide various sub domains and contexts, but in some cases, a new sub domain may not be so obvious, so the contradiction will be found when knowledge precipitates, so the context may also be added and reorganized. These are decisions that will rise to the strategic level. If you do not reconstruct the contradiction to the subdomain, it may lead to the design of some large mud balls.