首页 > 解决方案 > 领域驱动设计模型设置

问题描述

在过去的几周里,我一直在享受学习清洁架构和领域驱动设计的乐趣,现在我想将它用于个人项目来尝试一下。但是我在为我的域空间建模的一些关键概念上遇到了麻烦!我花了一些时间思考这个问题并在网上寻找示例,但觉得我可能以错误的方式思考这个问题。我试图建模的情况如下所述......

我的应用程序的目的是构建一组称为“组件”的 xml 文件。所有构建的“组件”形成一个整体“构建”。每个组件都包含大量属性,例如参数、摘要等。

到目前为止,我已经决定“组件”的属性将是值对象,而“组件”本身将是一个实体(因为它在应用程序中具有生命周期)。我也相信“构建”作为一个整体应该是一个实体,因为它的生命周期将是组件被实例化和构建的持续时间等。所以我正在努力解决的模型方面是我应该拥有多少聚合以及应该拥有什么(ier) 根是?一个“组件”是否应该是一个聚合,因为它们在构造方面经常被视为一个整体?但是,构建还需要是一个包含相关聚合列表(即“组件”)的聚合,可以吗?

任何有关这方面的指导或材料将不胜感激!

标签: c#domain-driven-designentitiesaggregateroot

解决方案


我的应用程序的目的是构建一组名为“组件”的 xml 文件

我认为你是从错误的角度来解决问题的。在 DDD 中,您应该首先独立于文件格式等基础设施对业务规则进行建模。聚合应该强制执行这些规则。但是,如果将某些数据转换为 xml 文件确实是您的程序的目的,那么 DDD 完全是矫枉过正,最好编写一个脚本或类似的东西来完成这项工作。


推荐阅读