DDD，数据库和数据列表

问题描述 投票：0回答：1

我是我第一个“真实”软件项目的开始，我想从头开始。 DDD的概念似乎是一种非常干净的方法，可以将各个软件部分分开，但是在实际中很难实现。

我的软件是测量跟踪器，本质上存储由时间戳和数据值组成的测量数据列表。

我的域模型

class MeasurementDM{
   string Name{get;set;}
   List<MeasurementPointDM> MeasurementPoints{get;set;}
}

class MeasurementPointDM{
   DateTime Time{get;set;}
   double Value{get;set;}
}

我的持久性模型：

class MeasurementPM{
   string Id{get;set;} //Primary key
   string Name{get;set;} //Data from DomainModel to store
}

class MeasurementPointPM{
   string Id{get;set;} //Primary Key
   string MeasurementId{get;set;} //Key of Parent measurement
}

我现在有以下问题：

1）因为我想保持我的域模型纯净，所以我不需要或不需要这些类中的数据库密钥。从数据库构建我的域模型时，这没有问题，但是我不知道如何存储它们，因为域模型不再知道数据库ID。我是否应该将其包括在Domain模型中？从数据库检索域对象时，是否应该创建将域对象映射到数据库ID的字典？

2）测量点本质上与测量本身具有相同的ID问题。另外，我不确定自己存储MeasurementPoints的正确方法是什么。在上面，每个MeasurementPointPM都知道它属于哪个MeasurementPM。查询时，只需根据其Measurement键选择MeasurementPoints。这是存储此类数据的有效方法吗？似乎随着越来越多的测量被添加而爆炸。将我的MeasurementPoints列表序列化为字符串并将整个列表存储为nvarchar更好吗？这将使添加和删除数据点变得更加困难，因为ID始终需要反序列化，重新序列化整个列表]

我很难找到解决这些问题的DDD的好例子，希望在那里的人可以帮助我。

database list domain-driven-design
1个回答
0
投票

我的软件是测量跟踪器，本质上存储由时间戳和数据值组成的测量数据列表。

您可能要仔细考虑是在描述服务还是数据库。如果您的主要用例是存储来自其他地方的信息，那么将领域模型引入其中可能不会使您的生活变得更好。

当新信息与旧信息交互时，域模型测试很有趣。因此，如果您只有数据结构，那么将很难找到一个好的模型（因为关键元素-模型实体随时间的变化-丢失了）。

那是...。

我不知道如何存储它们，因为域模型不再知道数据库ID。

这不是你的错。文学很烂。

最常见的答案是_people允许其模型受到O / RM问题的污染。例如，如果您查看Citerus示例应用程序中的Cargo实体，则会发现这些行隐藏在底部：

Cargo（）{// Hibernate需要}

//自动生成的代理密钥私人Long ID；

这是以下事实的间接结果：当掩盖之下的现实是您复制值在内存和持久存储之间。这就是说，如果您想要一个干净的域模型，那么您将需要一个单独的内存表示形式来存储数据，并且需要在两者之间来回转换的功能。

换句话说，您遇到的问题违反了“单一责任原则”-如果您使用与用于管理持久性的相同类型来建模域，那么结果将是两个问题。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.