我是一名程序员，我认为我在 OO 方面受过良好的教育。我相信 POCO (C#) 和只有 get/set 方法来封装数据的模型。3层域模型。
我正在寻找支持在服务层中具有简单域模型和所有业务逻辑以及用于数据访问的 DAL 的价值的文档。
马丁·福勒：
http://martinfowler.com/eaaCatalog/domainModel.html
http://martinfowler.com/bliki/AnemicDomainModel.html
是说（贫血）域模型没有价值，并且要使其具有价值，它必须处理总线逻辑或/和数据 CRUD 操作。我需要一些对 Martin Fowler 有反驳意见的好书。（这不是解雇 Martin Fowler 的情况，我尊重这项工作。我希望更好地了解我们在做什么以及为什么？）
你可以从……福勒本人那里找到反驳。
PoEAA，页。110、交易脚本：
无论您变得多么顽固，都不要排除事务脚本。那里有很多简单的问题，一个简单的解决方案将使您更快地启动和运行。
事务脚本并不完全是您描述的那种服务（它可能不使用域对象，甚至是贫血的对象），但它非常接近。
另外，请注意 POCO 的概念并不假设对象的愚蠢或贫血。您可以拥有包含行为的富域 POCO。POCO/POJO 描述了一个简单的本机对象，而不是用注释或属性修饰的对象，或者从框架继承特殊类的对象，通常用于持久性目的。
引用 Fowler，贫血领域模型：
本质上，贫乏领域模型的问题在于它们承担了领域模型的所有成本，而没有产生任何好处。
成本包括将您的对象映射到数据库以及您在设计（贫乏的）域模型时所付出的努力。如果您决定不需要 DDD 的好处，并且与贫血模型相关的成本是可以接受的，那么您就有了反驳的理由。
但是，请确保您的贫血模型 + 服务 + DAL（+UI？）比带有一些事务脚本的活动记录应用程序（Ruby on Rails？Grails？）便宜。
当我们想要简化一个复杂的问题，而不是“复杂化”一个简单的问题时，通常会应用领域驱动设计。再次引用福勒：
领域模型并不总是最好的工具。
分析您的需求，选择合适的架构并交付您的应用程序。
看一下DCI 架构，它将数据与行为分开，试图通过拆分导致彼此变化率不同的部分来控制软件演化。它还使用角色或特征的概念来实现将数据和行为重新组合在一起的所需功能。
有一本书解决了强调 DCI 的更广泛的架构主题：James Coplien的《敏捷软件开发的精益架构》 。