30次发布
0.2.141 | 2019年9月18日 |
---|---|
0.2.140 | 2019年9月16日 |
0.1.98 | 2019年9月9日 |
0.1.3 | 2019年8月25日 |
#18 in #design-pattern
210 每月下载量
在 2 个crate中使用了(通过 domain_derive)
28KB
83 行
域模式
本项目提供了领域驱动设计领域的模式。
仓库特性
此特性定义了仓库的特性,它是对数据库访问的类似集合的抽象。这个特性与标准库中使用的函数签名非常相似,因为这是最接近的类比。尽管如此,仍有一些关键的不同之处,主要围绕所有权的概念。标准库希望拥有它的值,但在数据库访问的类似集合抽象的情况下,仓库拥有数据并不合理。数据库拥有数据,并将这些数据传递给仓库,仓库构建一个实体,并将该实体返回给调用者。
由于抽象的性质,仓库更适合接收引用(因为它只需要将这些数据持久化到底层存储系统),并返回所有权的值。
与标准库的HashMap
API不同,当键已存在时,insert
不会更新键的值。这是为了防止对仓库的误用。逻辑与HashMap
的insert
方法相反。如果键已存在,则返回None
。如果键不存在,则返回实体本身。这在我们需要使用数据库中的计算数据更新实体并将其返回给调用者时非常有用。
此API与标准库的HashMap
API不同的另一种方式是,所有方法都返回一个Result
。这是由于我们可能无法与底层存储机制通信,或者出现需要传达给调用者的并发相关错误。成功情况与标准库HashMap
非常相似,而失败情况则传达了底层存储机制的问题。
实体特性
实体特征简单定义了实体必须具有某种持久的身份。这是通过一个单独的函数签名来建立的,该签名确保任何Entity
都必须有一个返回某种类型全局唯一标识符的id()
方法。
值对象特征
ValueObject
特征定义了值对象的特点,值对象是一个持有某些不可变值的对象,并验证传入的数据以确保其符合某些要求。例如,如果你有一个Email
结构体。在任何时候,这个结构体都应该只持有有效的电子邮件地址。如果Email
实现了ValueObject
特征,则实现者将需要编写一个try_from
实现,该实现应该调用它们的validate
实现,并在验证失败时返回错误,或在成功时创建一个值对象。值对象的一些规则包括
- 值对象是不可变的。
- 值对象应该验证用于构建它们的数据(在成功验证后它们持有的“值”)。
- 值对象没有全局唯一的身份。
许可证:MIT
依赖项
~0.4–1MB
~23K SLoC