我一直在编写分层的应用程序：
DB<->DAL<->BL<->服务<->演示
这就是引用的全部内容。也就是说，演示文稿没有对 DAL 的引用。
我们有一个要为客户编写的新应用程序，而客户提出的建议对我来说是陌生的。也就是说，WRITE 流经过 SL，但要从数据库中读取数据，希望我们在演示文稿中有一个 linq 查询，直接到 DAL。这似乎很奇怪，但有人告诉我，我的方式是老式的，我的方式，他们提出的方式本质上是一样的。
另外，我的业务逻辑通常驻留在 BL 中，这是一个单独的项目。但是客户希望业务逻辑在 DTO 对象本身中。
这是正常的吗？这基本上是领域驱动开发还是什么？我觉得奇怪的是，获取表单数据的 linq 调用位于表示层，而不是我对服务层方法的想法：
public MyPersonObject GetPersonByPersonId(int personId)
然后是 Business 中的相同方法，它可能会对所获得的内容应用一些规则，然后是具有 Linq 的 DAL 中的相同方法。
客户就是客户，你听说过CQRS吗？
您的客户可能会受到 CQRS 的影响，这是领域驱动设计中的一种新架构时尚。一般来说，它以不同的方式将命令和查询分离到数据库中。
但是在您的客户提出的方法中，传统的 DDD 和 CQRS 之间似乎混杂在一起，而 CQRS 内部不使用事件溯源。但它仍然可以正常工作，恕我直言，为表示层提供数据的查询是微不足道的，它本质上并不复杂。它就像报表系统只是从数据库中查询数据，你不需要为此使用 ORM。
另外，我的业务逻辑通常驻留在 BL 中，这是一个单独的项目。但是客户希望业务逻辑在 DTO 对象本身中。
业务逻辑应该在领域实体中，如果不是，似乎你违反了贫血模型反模式，它也不在 DTO 中。DTO是分布层与消费者之间数据传输对象的概念。
你所描述的绝不是DDD。虽然一些 DDD 实现确实使用拆分架构来处理查询和命令（CQRS 方法），但它并没有消除对应用程序良好分层的需求。
如果写入通过服务层，这可能意味着您的软件至少具有合理的复杂性，因此，应该通过中间的抽象层将表示与持久性分离。在 CQRS 中，该层通常采用 Facade 的形式，接受查询并返回包含所需数据的 DTO。
但是客户希望业务逻辑在 DTO 对象本身中。
DTO 代表数据传输对象。DTO 不包含任何业务逻辑，除了承载数据之外没有其他用途。