在 Clean Architecture 设计中，我们需要为每一层创建一个单独的 "Project" 吗？

Question

在Clean Architecture设计中，我们需要为每一层创建一个单独的“项目”吗？或者我们可以在同一项目上定义具有文件夹和命名空间的层吗？

我正在使用 Net Core 在微服务架构中设计一个新应用程序。我打算在我的设计中使用清洁架构原则。

我计划将以下项目结构用于我的每项服务。这是正确的方法吗？我正在尝试减少项目数量。

项目 1 - 演示文稿
项目 2 - 应用层、领域层、持久层（此处层由文件夹和命名空间隔离）
项目 3 - 基础设施
项目 4 - 横切

Answer 1

在开发之初，将所有内容放在一个地方似乎更好，但随着项目的发展，您将越来越难以维护各个组件的概览。

发生这种情况时，您可以决定移动代码，但这可能比在开始时分离代码更麻烦。

特别是一旦您开始考虑使用 nuget 包等，这可以帮助您确定哪些代码正在使用哪些组件。

Answer 2

我强烈建议你真正拥抱

关注点分离

软件设计原则。

正如我的评论所说，新项目的“文件夹分离”基本上是在乞求一个“大泥球”软件项目。

在新项目上添加图层（csprojs）就是这么简单。而且不这样做会非常非常短视。

一般来说，如有疑问，请选择“过度分离”。为什么？稍后“组合”是微不足道的。巨大的头痛和“稍后分开”的努力。

我的典型设置。

./src/BusinessServices/Optum.Flex.MyProject.BusinessServices.csproj
    WebApi Layer.  (and top layer for IoC "Compositon Root").  References everything below, except unit tests.

./src/BusinessLogic/Optum.Flex.MyProject.BusinessLogic.csproj
  Business Logic.  References Optum.Flex.MyProject.DomainDataLayer.Interfaces.csproj.  and Domain.csproj.  DOES NOT REFERENCE concrete EntityFramework.csproj.


./src/DomainDataLayer.EntityFramework/Optum.Flex.MyProject.DomainDataLayer.EntityFramework.csproj
  Concrete DomainDataLayer.  References Optum.Flex.MyProject.DomainDataLayer.Interfaces.csproj.  and Domain.csproj.  
  Will also contain Orm-Entites, Orm-Maps.
  Can also contain the "converters" from Orm-Entities to DTOS(pocos) and vice versa.  (Use mapster or automapper or hand map)

./src/DomainDataLayer.Interfaces/Optum.Flex.MyProject.DomainDataLayer.Interfaces.csproj
    Interfaces for DomainDataLayer.  
    The interfaces accept and return Domain objects, the DTOS/POCOS.

./src/Domain/Optum.Flex.MyProject.Domain.csproj
    DTOS (or POCOS).  Has ZERO REFERENCES TO ANY OTHER LIBRARY.  Simple Pocos/Dtos.


./src/UnitTestProjects/UnitTests.EntityFramework/UnitTests.EntityFramework.csproj
./src/UnitTestProjects/UnitTests.BusinessLogic/UnitTests.BusinessLogic.csproj
./src/UnitTestProjects/UnitTests.Domain/UnitTests.Domain.csproj

我更进一步

CQSP（命令查询分离原则）

https://martinfowler.com/bliki/CQRS.html

和

不要从其他服务“通过线路”传递 ORM 实体。

https://thorben-janssen.com/dont-expose-entities-in-api/

这些问题以及由此产生的所有讨论主要有两个原因：实体是 POJO。通常看起来它们可以很容易地序列化和反序列化为 JSON 文档。如果它真的那么容易工作，那么您的 REST 端点的实现将变得非常简单。公开您的实体会在您的 API 和持久性模型之间建立强耦合。两种模型之间的任何差异都会带来额外的复杂性，您需要找到一种方法来弥合它们之间的差距。不幸的是，您的 API 和持久性模型之间总是存在差异。最明显的是实体之间关联的处理。

https://jacquessmuts.github.io/post/modularization_room/

不要这样做。请。它打破了实施适当的关注点分离的项目所需的信息隐藏的核心概念。映射您的实体相反，您应该有两个不同的对象。您应该有一个代表数据库实体 (Orm-Entity) 的对象（Java 这是 JPA 注释对象和 C# 这是 Orm-Attributed 对象（不太优选）或 FluentMapped Orm-Entity），以及一个对象（“Dto”或“Poco”）用于传递纯数据。您的数据库模块应该是唯一导入 Room 库的模块。如果任何其他模块导入了数据库模块的那些实现细节，那么你就没有像你应该的那样隐藏信息。

并将此面包屑导航到“组合根”

https://blog.ploeh.dk/2011/07/28/CompositionRoot/

在 Clean Architecture 设计中，我们需要为每一层创建一个单独的 "Project" 吗？

In Clean Architecture design, Do we need to create a separate "Project" for each layer?

.net

software-design

microservices

asp.net-core

clean-architecture