2014-12-31 47 views
1

要结束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的评论。

+1

如果您的对象具有标识(即代码),您将通过它检索它,它不是一个值对象。 – DoctorMick

+0

我对此100%确定。例如,如果我有一张内含税表的表格。真正的基本结构可以是ID/CODE/PERCENTAGE/LABEL。在使用这种结构时,20%的税和20%的税之间有什么不同?我认为没有。如果我们添加时态属性,也许这可能是一个实体,但只是一个百分比和一个代码来获取它,是不是一个valueObject? – Archange

+0

不,价值对象没有身份,不存在没有实体将其关联的实体。这听起来像我们正在谈论参考数据,所以这可能是有用的:http://stackoverflow.com/questions/5478253/loading-a-value-object-in-list-or-dropdownlist-ddd。如果附加到某物(某个订单或类似物)时价值没有变化,那么此时该订单的税可能是一个价值对象。 – DoctorMick

回答

0

我会挂在你的国家的例子。在大多数情况下,国家将是一个价值对象。没有什么会提及一个国家实体,并且应该知道,如果国家的价值观改变了,它仍然是同一个国家。事实上,这个国家可以被视为一个枚举,以及一​​些令人讨厌的资源查找功能,可以将Iso3转换为有用的显示文本。我们所做的是,我们将它定义为一个具有iso3,displayname和一些其他静态信息的值对象类。现在,从这个值对象中我们定义了一种“权力枚举”(我仍然错过了一个标准术语)。实现国家/地区值对象的类为其每个值(每个国家/地区)和显式转换运算符从/到int获取私有构造函数和静态属性。现在你可以把它看作是你的编程语言的正常枚举。除了具有更多属性字段之外,普通枚举的优点是,它也可以具有方法(当然,查询方法不会更改对象的状态)。你甚至可以使用多态(一些国家的行为与其他国家不同)。您也可以从数据库表中加载枚举的内容(而不是静态然后使用静态lookupByIso3方法)。

这也可以与其他“enum like”值对象一起制作。想象一下货币(它可能有实现多态的转换方法)。尽管如此,处理每日汇率是一个不同的话题。

如果这组值不固定(例如邮政地址等其他值对象候选),则它不是值对象枚举,而是可以使用所需值实例化的标准值对象。

要决定您是否可以像某个值对象一样生活,您可以使用以下问题:您想要复制语义还是引用语义?如果您更改过该对象的属性,那么您使用它的所有地方是否也要更新,还是应该保持原样?如果后者比“已更改”对象是新的不同值对象。另一个问题是,如果你需要追踪一个对象的变化,意识到它仍然是“相同的”,尽管它改变了值。如果你有一个值对象,你只想要特定的实例存在,它就是上面描述的一种枚举类型。

这是否帮助你?

+0

国家可能拥有大量属性,例如电话代码,货币,时区,语言,欧盟成员,增值税号码前缀等。那么你怎么能确定你永远不会需要这个? –

+0

我认为在DDD中,你不会模拟你可以从现实中想象的所有属性的国家,而只是有界的上下文需要的属性。在另一个有界的环境中,你可以使用其他需要的属性对它进行建模。你所描述的事情也是不同的概念,而不是简单的国家属性。我所说的“国家”就是国家本身。不像人口统计。但即使你必须改变它的一些属性,问题仍然是如果这需要在此之后是“相同的”,或者如果你可以把它作为一个“新”的价值。 –