域模型：应该包括Logging，Audit，Persistence等内容

Question

我很难说服我们的架构师，域模型应该只包含业务域的基本元素。诸如类是可持久的，需要日志记录和审计以及它具有RESTful URI的事实不应该驱动域模型。稍后可以使用接口添加它们。

我们的医疗保健信息管理系统。在非常粗略的层面上，它是一个用户登录并访问其医疗保健信息的系统。他们可以与他人分享这些信息，并成为他人信息的监护人（思考角色）。但是由于早期流行的一些声音字节 - 比如“Everything应该是一个REST资源” - 模型现在有一个名为Resource的顶级类，其他所有类都来自。

我试图让他看到域模型应该由明确定义的概念驱动，例如User Account，HealthDocument，UserRole等，它们是业务的不同实体，它们之间具有特定的关联。在资源类下使用所有内容使得我们的模型除了可能不正确之外还不灵活 - 如果一切都是“资源”，那么如何描述“用户访问资源”的概念。

但他希望我告诉他为什么以他的方式这样做是个糟糕的主意。我不知道如何正确表达，但我所有的OO本能都告诉我它不正确。有什么想法吗？

Answer 1

我认为你应该解雇你的建筑师。

REST中的所有内容都是资源这一事实并不意味着您的所有类都需要从“资源”派生！

不，这些实现依赖项不应该是域模型的一部分。提醒您的架构师，即使您使用不同的技术（例如SOAP）实现代码，域模型应该是相同的。

Answer 2

从OO的角度来看，恕我直言，如果您对系统（不是软件）进行建模，您将拥有模型中的所有域概念及其关系和行为。多层架构中的域模型，域驱动设计甚至模型视图控制器正是我所描述的实现。因此，域模型不包含任何技术细节。这种分离有什么用呢？为什么要使用它？其中一个原因是代码易读性，一旦您将业务逻辑与技术方面分开，您就可以轻松发现其中一个或另一个不会被另一个工作干扰。另一个原因是技术平台的独立性。有时可能需要您对系统进行一些技术更改，当您只需要在一个地方进行更改时，这将更容易。另一个原因是业务敏捷性 - 能够在不需要技术更改的情况下更改业务逻辑（系统模型中指定的内容）的工作方式。这是使用OO设计原则的关注点分离。