单一职责原则与贫乏/丰富领域模型有何关系？

Question

目前正在对从另一个团队接管的东西进行一些代码审查，并对应用 SRP 及其与贫血或丰富域模型（由 Martin Fowler 定义）的关系存有疑问。 富域模型的概念是拥有智能对象，不仅可以设置/获取其属性，还可以执行一些更复杂的业务逻辑。我想知道它如何适应SRP？

假设我的模型类具有一些属性，可以公开这些道具并对其属性提供一些简单的计算。下一个要求是能够将该对象数据存储在不受我控制的某个存储对象中，如下所示：

class MyObject {
    // get set
    // parse sth
    
}

存储中的存储方法

   storage.store(key, object);

如果 MyObject 有这样的存储方法，它是否违反 SRP

public void store(Storage storage) {
    storage.store('keyOne', fieldOne);
    storage.store('keyTwo', fieldTwo);
}

从该对象的 pov 来看，这是一个很好的选择认为能够存储其状态。 其他方法可能是在这里引入某种服务，然后这样做：

public StorageService {
    private Storage;
    // constructor here
    ....
    public void store(MyObject myobj);
}

您能给我指出任何我可以阅读的有关此问题的链接吗？我在这里找到了一个线程，但它并没有完全回答我的问题。

DDD中是如何解决的？ DDD 中的模型根据定义是丰富的，并且可以被视为具有太多的职责。

Answer 1

富域模型 (RDM) 意味着控制模型行为的逻辑属于模型内部，而不是将模型视为数据getter/setter。这并不意味着包括持久性、安全性、如何在 GUI 中显示模型等在内的所有内容都需要位于模型内。

RDM 和SRP 齐头并进，并不冲突。

违反 SRP/RDM：

Car {
   // possibly violates SRP
   storeInDatabase();  
   // smells like anemic domain model
   getEngineState();   
}

遵循 SRP/RDM：

// usings aspects to remove cross-cutting concerns from the model and follow SRP
@DatabaseSerializable 
Car {
   // rich domain model encapsulates engine state and exposes behavior
   drive();            
}

Answer 2

“DDD 中的模型根据定义是丰富的，并且可以被视为具有太多的责任”是对 DDD 的简单化解释。这始终取决于您的模型有多好。您可能会使用 DDD 创建糟糕的模型（例如创建具有太多职责的对象或创建贫乏的模型）。 DDD 和 SRP 是两个值得遵循的良好实践，就像重构、TDD 等等一样，但您应该用您的经验和判断（或其他人的）来补充它们的使用。任何事物都有其优点和缺点，不要教条地应用任何实践。

Answer 3

@Garrett Hall

我有点不同意你的说法“RDM 和 SRP 齐头并进，它们并不相互冲突。”根据我的经验，当过分强调 SRP 时，就会导致领域模型贫乏。 “不，我们不能做，甚至不能帮助支持任何持久性，不，我们不能做 21-CFR11，不，我们甚至不知道 GUI 是什么......”并且你的班级最终会做什么都没有，只有一个贫血领域模型。

如果过分强调 RDM（这就是我容易陷入的方向/错误），那么 SRP 就会完全被抛在一边，您最终会注意到您的类有 100 个方法，并且显然做得太多了。

您需要找到一个平衡点，即 RDM 和 SRP 都能实现的折衷方案。找到这种平衡是很困难的，而且通常需要团队内部更多的直觉和政治，而不是技术头脑或规则。

“认识你自己”。如果您像我一样，倾向于过于复杂的课程，请注意。当你看到别人的类甚至对你来说也看起来太复杂时，那就是一个很大的危险信号。同样，如果您知道自己对 SRP 非常狂热，并且看到一个类即使按照您的标准看起来也很贫乏，那么这就是主要的代码味道。

现在，在某种程度上回答OP关于存储的问题，我认为很大程度上取决于存储的稳定性、标准和抽象程度。如果存储是某种标准的 XML、CSV 或 RDB 抽象，那么我对知道如何存储自身的对象绝对没有问题。