处理贫血域模型

我试图将我的DAL与业务层分开，并且这样做时，我决定避开任何ActiveRecord方法并使用DataMapper方法。换句话说，我的域对象不会照顾自己。在这样做的时候，我似乎正在蚕食“贫血域模式”的反模式。例如，我的程序中的一个实体是一个组织。处理贫血域模型

一个组织被表示为这样的事情：

class Organization { 
    private $orgId; 
    private $orgName; 

    // getters and setters 
}

所以基本上这个组织确实没有什么比其他的行为作为“袋”（马丁·福勒说）的一些数据。在PHP世界里，它只不过是一个荣耀的数组。没有与之相关的行为。

在程序中的行为，我一直坚持在“服务级别”类中，像OrganizationService，它主要作为这些对象和DAL之间的中介。

除了PHP可能出现的缩放问题（我还有其他原因，为什么我坚持要在这些对象中“装袋”我的数据），这种方法完全关闭吗？

你在这些情况下如何处理你的领域模型？也许一个组织不是我的第一个地方的一部分？

来源

2009-06-19 blockhead

嗯，看来这样的开头，但是当你重构你的代码越多，你会得到一些行为为您的组织类...

，我可能会认为现在

一个例子如果你有人（雇员），你可能想把他们与组织联系起来。所以，你可能有一个方法AssociateEmployee(User employee)，它可能会在你的组织类中找到它的位置。

或者，你可能会改变位置的公司，而不是在三步设置，如地址，城市，状态参数，您可以添加ChangeLocation(Street, City, State)方法..

只是走一步看一步，当你遇到一些代码你的BL /服务层似乎应该属于域，将它移到域中。如果您阅读福勒，当您在代码中看到它时，您会很快得到它。

来源

2009-06-19 17:40:04 zappan

如果域模型无法访问DataMapper，那么如何在域模型中使用AssociateEmployee方法？ – bestattendance 2015-01-27 20:24:52

现在可能只是贫血？

例如，我曾经开发过一次会议/会议注册网站。它只从一次会议开始。

还有一个会议班，只有一个例子，但第二年我们举行了会议，扩大了会议并增加了新的属性（举行两次背靠背的会议），所以显然它不是充分发展，因为我们然后添加了可能包含多次会议的会议组。

因此，我认为重要的是要记住，随着时间的推移域名会随着时间而改变，并且您的模型可能最终会被重构，所以即使您认为它很贫乏，它也可能只是有些过于前瞻性（就像您的组织班级将开始获得一些设置，规则或偏好或其他）。

来源

2009-06-19 17:36:57

您的实体并非贫血，因为您正在服用一种不应该在那里开始的可重复性。坚持和提取实体是知识库的责任。真的，你的行为应该在你的实体不在服务层。但解释什么是远远超出简单的答案。 Eric Evans的DDD是一个很好的起点。

来源

2009-06-19 17:37:20 epitka

您可能还会认为，如果您没有很多业务规则，或者域不那么复杂，那么DDD对您而言可能会造成太多的开销。对于大型，复杂的领域来说，DDD是一个很好的解决方案，但是如果你只是在数据输入中进行数据输入，DDD会带来很多开销和复杂性。 DDD设计起来比较困难，并且固有地增加了复杂性，所以为了证明这一点，问题域的复杂性应该超过这个范围。

这就是我要添加到zappan和外延。

来源

2009-06-19 18:01:54 jlembke

我碰巧在我的域的其他部分有更复杂的业务规则。这个特定的应用程序是一个组织设置中国拍卖的系统（http://en.wikipedia.org/wiki/Chinese_auction）。应用程序的其他方面，如与拍卖奖品和购物车的迭代实际上确实包含相当数量的逻辑。总而言之，我的主要目标不一定是DDD，而是关注点的分离。 – blockhead 2009-06-19 18:15:18

处理贫血域模型

回答

相关问题