我已经开始了解DDD，我有几个问题，以便我可以提高对它的理解。
所以典型的DDD架构看起来像这样
域层=＆gt;该层应该是技术不可知的，应包含以下内容
Domain.Entities（与持久层实体不同，应该只包含验证规则？任何其他域名业务应该放在这里吗？）
Domain.ValueObjects（在域中不需要唯一的对象，应该只包含验证规则）
Domain.Services（该层应包含业务逻辑，虽然与Aggregate相关，但不适合Aggregate本身。协调器用于需要多个Domain.Entities和/或Domain.ValueObjects协同工作的操作）
Domain.Factories（这个层在某种程度上是不完全理解的，我的意思是它的责任是创建聚合或什么？）它纯粹是工厂设计模式还是与它不同？
Domain.Repositories（这个层也是模棱两可的，除了我知道这个层负责与外部服务通信，它应该处理什么类型的业务逻辑？）
反腐败层（此层应充当域层与应用层之间的网关，它应负责将响应和请求从一层转换为另一层）
Application Layer =＆gt;应该仅用于以客户易于理解的格式公开数据。过滤在此层（Linq-To-SQL）/（Linq-To-Entity）
中完成客户（最后一层）=＆gt;应该没有任何逻辑，只暴露应用层服务提供的模型。
我看到的其他图层
在多个有界上下文中共享的Shared.Kernel（Domain.ValueObjects / Domain.Entites（不是AggregateRoots））
Infrastructure.Domain.Common（在整个域中共享，ex AggregateRoot，BaseEntity，BaseValueObject等）
Infrastructure.DataAccess.Provider（示例EntityFramework / nHibernate / MongoDriver，此层应与谁通信？应用层？
答案 0 :(得分：6)
DDD没有定义分层方法。它只是建议使用一个。我建议阅读Clean / Hexagonal / Onion分层。这种方法与DDD一致并得到广泛认可。
不要让不同的名字欺骗你，这些方法非常相似，如果不相同的话。
答案 1 :(得分：5)
老实说，域驱动设计的前提将根据可能决定应用程序的应用程序需求，业务任务和底层架构而有所不同。对域驱动设计的最简单解释。
数据层：抽象的数据层，从图形用户界面中分离出关注点。
域层：您的业务规则和逻辑，是公司要求的基础，使命。
服务层：不是必需的，而是充当图形用户界面和数据层之间的中介。在建模数据与商业实体之间进行简明扼要的翻译。
应用层：您的用户界面，以有意义的方式为用户提供核心业务功能。
重要的概念，没有层依赖于彼此。他们都是独立的，互相恭维。您已经涉及更具体的背景概念，在每个应用程序中都没有相关性或可行性。
根据您的示例，您可以向外抽象您的域，使该层可能贫血，而不是保留足够的相关或有用信息。传统的分层应用程序，如果以微服务方法编写，循环方法（清洁架构）或分层方法可以是域驱动设计。因为每种方法或风格都使用域驱动设计的基本目的，捕捉业务目的和使命。
应用程序不是域驱动设计，因为您有一个图层。您的应用程序将遵循一系列原则，以符合域驱动设计。这些原则是为了确保您的应用程序适应业务变化。掌握代表业务的核心逻辑，同时随着业务目标在公司整个生命周期中发生变化。它们经常落在松散耦合的一边。
您提到的上述图层中有一半是解决问题的复杂模式。所有工具都有一个目的，如模式，螺丝刀用于问题x，工厂可以解决x，但存储库可以解决y。并非每种模式都适合所有用途。他们不是解决问题的方法。
这个主题有很多材料。福勒，埃文斯，沃恩和无数其他人。
答案 2 :(得分：3)
从DDD开始的地方是“蓝皮书”：Domain Driven Design by Eric Evans
典型的DDD架构如
a layered architecture。埃文斯重述了四个概念层
在第4章（隔离域）中，Evans指出
专门解决域中问题的软件部分通常只构成整个软件系统的一小部分，尽管其重要性与其大小不成比例。为了应用我们最好的想法，我们需要能够查看模型的元素并将它们视为系统....我们需要将域对象与系统的其他功能分离，这样我们就可以避免混淆域其他概念的概念仅与软件技术相关或完全忽视域名....
在“域层”中，Evans认识到两组不同的问题。
域实体，价值对象和域服务为软件中的业务建模（第5章）。换句话说，这些元素是您的领域专家可以识别的概念的模型。
存储库和工厂是生命周期问题 - 与专家认可的业务并不严格相关，而是充当应用层和域层之间的边界。
在Evan的表述中，业务规则的验证通常存在于域实体（而非域服务）中。正如OO样式中常见的那样，域实体组合了状态（域值）和行为（变更规则） - 由于域执行的代码，对持久层实体（您是对的，不是同一个事物）的任何更改都会发生实体。
Anti corruption layers更多关于与外部数据源（可能是遗留系统）的集成，然后是关于与应用程序层集成。
在现代应用程序和它所依赖的遗留系统之间实现façade或适配器层。该层转换现代应用程序和遗留系统之间的请求。使用此模式可确保应用程序的设计不受遗留系统依赖性的限制。
您可能希望查看github上提供的DDD示例应用程序。这是一个关于不同部分如何组合在一起的体面草图。
注意：现在，分层架构已经失去了其他一些替代方案，我们开始看到更多关于使用功能核心（而不是OO风格）实现域模型的工作。