班上有“太多价值对象”吗？ （我正在实施DDD）

Question

注意：我正在使用PHP，但我认为这个问题会被认为是语言不可知的。我也在实施“lite DDD”，但我不认为这也限制了这个问题。

我有一个类（实体）有很多属性可以设置（我也有很多的实体行为，所以它不是贫血的领域模型）。

例如，我有一个类似下面的字符串许多特性：

public function setFirstName($firstName) 
{ 
    // Removes all non-printable characters and extra spaces. 
    // Also converts all "look-a-like" quotes to the standard quote character. 
    $firstName = Helper::cleanName($firstName); 

    if(empty($firstName)){ 
     throw new \Exception("first name is required"); 
    } 

    $this->firstName = $firstName; 
} 

Adhereing干，我看到在创造一个“干净的名字”值对象的利益。但是这会将我的所有字符串属性转换为这些值对象。我还有其他属性，这些属性是我将变成Carbon日期值对象的日期。最后，似乎几乎所有的财产（将被持续）已经成为一个价值对象。我担心我是否过度使用这种方法，或者是否有任何与内存相关的问题可能出现（特别是在这些实体的较大集合中）。

如何确定类是否过度使用值对象？ IE浏览器。对于要封装为值对象的逻辑量，是否存在最低标准？我是否通过使几乎所有属性（将被持久化）成为一个值对象来炸毁内存？有没有人遇到过可能有超过30个值对象的类的问题？

Answer 1

根据Mathias Verraes的精彩演讲Unbreakable Domain Models，他提到Value Objects是编程的“核心和灵魂”。所以我认为最终的答案是在使用Value Objects时不会害羞。

但是，在考虑验证类型之后，我提到了我的问题（清除了这些名称中的字符等），我决定将其转换为表单输入处理程序类。在进入域之前，在“应用程序级别”进行一些清理感觉好一点。当然，如果我开始有任何需要域逻辑的验证，那么我应该始终在域级别上进行验证。我认为碳日期应该留下来。我也有一个名为“urlSafeName”（或slu））的属性，我正在考虑制作一个Value Object（需要一个字符串并将其变成一个更“漂亮的URL”形式）。

我仍然有点担心VO的数组，它可以代替数据库中非常小的表。例如，职位名称的VO（总裁，首席技术官，首席开发人员等）。我必须确保阵列将保持在一个可管理的大小，但这个大小当然会是主观的。如果我有一个地址VO和一个cityId，stateId和countryId，那么我可能只想将它们存储为Ids，而不是将这些城市，州和国家的所有名称存储在VO中（但应该在查找表中在数据库中）。