领域驱动设计

领域驱动设计

限界上下文

划分领域边界，边界内领域模型保持一致，

强调内聚，并与边界外的领域模型解耦。

领域、子域

上下文映射图

多个系统之间会发生关系，存在交互，这也必然会在各

自的Bounded Context上有所表现。上下文图
（Context Map）便是表示各个系统之间关系的总体视图

共享内核

将两个团队共享的子集剥离出来形成共享内核

双方进行持续集成

客户/供应商

不同系统之间存在依赖关系时，下游系统依赖上游系统，

下游系统是客户，上游系统是供应商，双方协定好需求，
由上游系统完成模型的构建和开发，并交付给下游系统使用，
之后进行联调、测试。这种模式建立在团队之间友好合作和支持的情况下

追随者

如果上游系统不合作，这时候“客户/供应商”模式就不凑效了，

那么下游系统只能去追随上游系统，
下游系统严格遵从上游系统的模型，简化集成

防腐层

如果上游系统的模型不友好，

不适合下游系统的场景，但是下游系统又必须依赖于这些模型，
这时候我们需要使用防腐层（Anticorruption Layer）模式将上游系统的影响降低。
这种模式也是非常常见的，通常出现在系统间对接时，
使用trasport+resolver的方式完成服务调用和协议转换。
其中的resovler便承担了防腐的作用。

公开主机服务

能够允许系统将一组service公开出去公其他系统访问，

在互通模型的同时，减少了系统间的耦合
现在很火的微服务架构也可以理解为此类模式的实现形式

各行其道

当两个系统之间的关系并非必不可少时，

两者完全可以彼此独立，各自独立建模，独立发展，互不影响。

架构

实体

有唯一标识，可变的业务实体对象

它有着自己的生命周期。比如User、帖子等。

值对象

没有唯一业务标识，通常依附于其他领域实体，值对象的内容不可变，

要么被整体替换。如：用户点赞行为等。

领域服务

当某些业务行为无法归类到某一个Entity/Value Object时，

我们便可以创建领域服务来完成。
比如：账户转账场景，涉及到两个不同的Account实体，
再比如社区的敏感词过滤场景，帖子可以用，评论亦可以用，
因此可以抽离到ContentFilter中完成

领域事件

领域中发生的异步处理事件、异步消息通知等，

比如：异步写入的登录历史记录。
通常借助消息队列实现。

模块

聚合

是一组业务关联度很强的实体/值对象集合

每个聚合都有一个根实体（Root Entity）
通过根实体可以路由到整个聚合

工厂

用于复杂领域对象的创建/重建。

重建是指通过respostory加载持久化对象后，
重建领域对象。

资源库

严格意义上将仓库是基础设施层的东西，

但是为了保持领域模型的整体性，
我们将仓库的接口定义放到领域中
，这样可以在领域中约束实体/值对象的增删改查接口，
同时还可以方便地完成仓库的内存形式实现，
使得领域模型弱依赖于持久化层。

集成限界上下文

应用程序