要结束2014年,我想到了一个简单的问题。 我想更多地使用“DDD”,并且我正在尝试使用各种用例来了解有关DDD的更多信息。DDD valueObject和数据库模式
我现在用例是:
- 我们有一个使用我们公司的一个经典模式的新的数据库模式:造型我们的命名表作为“ID /密码/标签”。例如,我认为这是一个非常经典的例子。
但是在面向对象的世界中,当使用像JDBC或QueryDSL这样的API时,事情就变得“合并”了。我需要通过其代码获取对象,检索其id或加载完整对象,然后将其设置为另一个对象中的一对一关系。
我想知道:
- 这种命名法的可以是一个枚举(或具有根据显影剂字符串cosnatnts的类)。在DDD方面,它是我的ValueObject
- 数据库中的id/code/label不是i18n友好的(这不是先决条件),所以我没有看到它的优点。除非动态更新表,并且用例“从该表中加载的组合框中挑选某些内容并与另一个对象建立关系:但是,这都是因为如果您必须应用业务规则,则需要知道新代码。等等等等)
我的问题是:
- 你经常使用的ID/OCDE /标签图案在你的数据库模型
- 怎么做你的命名数据模型(国家是?也许不是最好的例子:)但是不管你如何模型化它?没有多想我会说国家的数据库表;但对于某些状态:“有效,等待验证,拒绝”?
- 你使用这种模式建模你的valueObjects吗?
- 或者您是否使用了大量的枚举,并且只将toString(或ordinal)存储在数据库中?
在Java OO对象世界中,我目前认为操纵从数据库加载的对象的枚举比较容易。例如,我需要构建存储库来加载它们。将它们用作枚举将会非常简单。我在这里搜索一些recomfort,或者我错过了这么明显的东西?
谢谢
在2015年见!
更新1: 我们可以创建一个“预算”,第一个是标记为初始,下那些被标记为“纠正”(与增量)。例如,我们可以有一个预算清单:“初始预算”,“纠正预算#1”,“纠正预算#2”。
为此我们有这样的数据库设计:一个预算表,一个带有外键的版本预算表。版本预算只包含一个ID,一个CODE和一个LABEL。
Personnaly,我想删除此表。我没有看到这种结构的优点。从OO的角度来看,当我创建预算时,我可以查询数据库以查看是否需要创建一个Inital或Corrective预算(使用计数查询),然后我可以为我的新预算设置正确的枚举。但是在目前的设计中,我需要使用我想要的代码来查询数据库,选择ID并设置ID。所以是的,它确实是面向数据库的。 DDD部分在哪里? ValueObject是描述,量化某些事物的东西。在我看来,对我来说很好。版本描述了我的预算的当前状态。我可以勉强两个版本,但检查他们的代码,他们没有生命周期(我不希望这个特别)。
如何处理这种类型的用例?
这只是一个简单的例子,因为我发现如果你问一个数据库管理员,他肯定会说所有这些看起来都不错:使用主键,建模关系,强制约束,使用外键和避免数据重复。
再次感谢Mike和Doctor的评论。
如果您的对象具有标识(即代码),您将通过它检索它,它不是一个值对象。 – DoctorMick
我对此100%确定。例如,如果我有一张内含税表的表格。真正的基本结构可以是ID/CODE/PERCENTAGE/LABEL。在使用这种结构时,20%的税和20%的税之间有什么不同?我认为没有。如果我们添加时态属性,也许这可能是一个实体,但只是一个百分比和一个代码来获取它,是不是一个valueObject? – Archange
不,价值对象没有身份,不存在没有实体将其关联的实体。这听起来像我们正在谈论参考数据,所以这可能是有用的:http://stackoverflow.com/questions/5478253/loading-a-value-object-in-list-or-dropdownlist-ddd。如果附加到某物(某个订单或类似物)时价值没有变化,那么此时该订单的税可能是一个价值对象。 – DoctorMick