我不清楚如何设计课程：
这种反模式的根本恐怖之处在于它是如此相反 面向对象设计的基本思想;这是结合 数据并将它们一起处理。贫血领域模型只是一个 程序风格设计，恰好是对象偏执狂的那种东西 像我一样......自从我们在Smalltalk的早期以来一直在战斗。 更糟糕的是，许多人认为贫血物体是真实的物体， 因而完全忽略了面向对象设计的重点 所有关于。在贫血领域设计中，通常是业务逻辑 在单独的类中实现，这些类转换了状态 域对象。福勒调用这种外部类事务 脚本。这种模式是Java应用程序中的常用方法， 可能受到早期版本EJB等技术的鼓励 实体Bean，以及继.NET之后的.NET应用程序 三层服务应用程序架构所在的对象 属于“商业实体”类别（尽管商业 实体也可以包含行为）
数据传输对象与业务对象之间的区别 数据访问对象是DTO没有任何行为，除了 用于存储和检索自己的数据（访问器和更改器）。 DTO是不应包含任何业务逻辑的简单对象 这将需要测试。
参考维基百科
似乎 DTO应仅用于在网络服务之间共享数据，但，同时， Active Record会知道其持久性在DB上也不好。
那么在课堂上应该采用哪种逻辑来组合从数据库中获取的数据呢？
答案 0 :(得分：1)
让我们弄清楚一些概念：
域模型：是包含业务规则的模型。它由代表业务及其流程使用的概念的对象组成。
DTO ：顾名思义，数据传输对象是一种将数据从域模型传递到域模型的方法。 DTO在应用程序的不同层上有多种用途：
资源：是从RESTful API返回的DTO。
DAO：是DTO发送到持久层还是从持久层返回。
视图模型：DTO是否发送到表示层的视图并从视图返回。
因此，您看到DTO是一个非常笼统的概念，可以在应用程序中以多种方式实现。
域模型由业务对象（也称为域对象）组成。它不是由DTO组成的。
这些对象必须强制执行业务规则，并通过公开方法来做到这一点。如果将这些规则放在其他地方，则域对象必须公开其内部数据（有效地成为DTO），因此包含逻辑的对象可以对其进行处理。
经验证明，这很难维护和更改，以适应将来的需求。这也与OOP原则背道而驰。这就是为什么它被认为是反模式，甚至被命名为：贫血域模型的原因。
答案 1 :(得分：0)
您应该拥有自己的域名实体。您可以在持久层中使用Active Record。将其视为没有任何功能的数据库表，但要保存和检索数据库中的对象。然后，您可以让工厂使用AR中的数据创建域实体。现在，您可以自由地使用多态，设计模式并将oop原则应用于域实体。
这个想法不是将逻辑放入AR类。使用它们只是因为您不想编写直接的SQL查询。
用户AR映射到Users表，但是根据该数据，工厂可以构建订户或用户。我在这篇博文中写了一篇关于这个的文章： http://thesolidphp.com/reducing-code-complexity-through-good-design/