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