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