DDD 笔记
< 返回列表时间: 2020-06-28来源:OSCHINA
[TOC]
名词解释 领域驱动设计 核心是不断提炼通用语言并用于与领域专家等团队所有成员交流,并用代码来表达出一个与通用语言一致的领域模型。 通用语言 通过团队交流达成共识的能够简单清晰准确传递业务规则的语言(可以是文字、图片等)。 领域 软件系统要解决的问题域,是有边界的。领域一般包含多个子域,子域根据其功能划分为核心域、通用域、支撑域。 限界上下文 描述领域边界,一个限界上下文可能包含多个子域,但一般实践上都以一对一为好。应用单元和部署单元一般也与限界上下文一致。
领域模型
对我们软件系统中要解决问题的抽象表达(解决方案)。模型一般在一个限界上下文中有效。 模块(Module) 聚合根(Aggregate Root) 实体(Entity)区别于 值对象 的地方在于 实体 有着 唯一的标示 值对象(Value Object)它不应该成为领域内的某一个东西,而 仅仅是 描述领域内的一个 概念 工厂(Factory) 领域服务(Domain Service)无状态的操作,用于实现某个特定领域的任务。当操作不适合放在聚合中或者 值对象 中的时候,此时就应该放置在领域服务中。 仓储定义(Repository) 领域事件(Domain Event) 限界上下文(Bounded Context)
对于值对象,它不应该成为领域内的某一个东西,而仅仅是描述领域内的一个概念 。
首先针对 实体 以及 值对象 ,我们应该 尽量使用 的是 值对象 而非实体。 实体 和 值对象 才是最重要的DDD建模对象,如果反而首先使用领域服务,容易导致“贫血领域模型”。
当值对象创建出来之后,就不应该再去修改,也就是 值对象的不变性 。 值对象可以在创建对象化之后直接处理掉,不用担心客户端对值对象的修改问题。 领域实现: 用户界面 应用服务 领域模型 基础设施 服务暴露 仓储实现 反腐层实现 实践步骤为: 找到子域 识别核心域、通用域、支撑域 确定限界上下文映射 在每个子域内设计领域模型 实现领域模型和应用
参考: Value Object & Entity & Domain Service
热门排行