我试图在我的项目中实现DDD,并且我使用Firestore作为我的持久性基础结构。Go中的Firestore有一些特定的类型,如*firestore.DocumentRef
。
我认为我应该把它放在我的实体结构中,因为它应该代表我的模型,但是我的实体也应该是数据库无关的(我认为)。
那么,我应该如何从DDD的角度处理这个实体/结构:
type Holder struct {
SocialReason string `firestore:"social_reason" json:"social_reason"`
Contact value.Contact `firestore:"contact" json:"contact"`
Location value.Location `firestore:"location" json:"location"`
SubmissionDatetime time.Time `firestore:"submission_datetime" json:"-"`
UpdateDatetime time.Time `firestore:"update_datetime" json:"-"`
Status string `firestore:"status" json:"status"`
LastModifier *firestore.DocumentRef `firestore:"last_modifier" json:"-"`
CEP string `firestore:"cep,omitempty" json:"cep,omitempty"`
Country string `firestore:"country" json:"country"`
Region string `firestore:"region,omitempty" json:"region,omitempty"`
City string `firestore:"city,omitempty" json:"city,omitempty"`
}
发布于 2021-03-11 08:10:50
您应该避免在您的领域中表示任何类型的实现--特定的技术选择,除非--但不太可能--它们确实是所述域无处不在的语言的一部分(在您的示例中似乎并非如此)。
有一个关于使用Golang实现DDD的很棒的博客系列,附带的代码库是随着这个系列引入更多DDD相关概念而发展起来的。检查狂野训练示例。
您可以直接从这些代码中学习,因为他们还使用Firebase作为其端口和适配器体系结构中的存储实现之一。它们还具有SQL和InMemory (用于测试)存储实现。
那么,它们如何表示存储库之外的firestore.DocumentRef
呢?作为一个简单的string
。例如,见GetUser() ..。
/内部/用户/firestore.go
type db struct {
firestoreClient *firestore.Client
}
func (d db) GetUser(ctx context.Context, userID string) (UserModel, error) {
doc, err := d.UserDocumentRef(userID).Get(ctx)
// More stuff to get the user model.
}
需要注意的是,对于用户管理,他们不使用DDD,而是使用基本CRUD (他们的简单用例用于用户管理,他们选择放弃DDD会带来的额外复杂性)。
完整的DDD设计的例子出现在培训师和培训领域。这里有更多的复杂性(例如,在处理事务方面),所以我提到了解释这些概念的Repository模式:简化Go服务逻辑的一种无痛方法。
但是,您可以清楚地看到域概念(存储库接口)和实现(存储库适配器)之间是如何划分的。例如,在培训领域,实现Hour
https://stackoverflow.com/questions/65903156
复制相似问题