在清洁架构设计中，我们是否需要为每个层创建一个单独的“项目”？

Question

在清洁架构设计中，我们是否需要为每个层创建一个单独的“项目”？或者我们可以在同一个项目中用文件夹和名称空间定义层吗？

我正在使用Net在MicroServices架构中设计一个新的应用程序。我计划在我的设计中使用清洁架构原理。

我计划为我的每一个个人服务使用以下的项目结构。这条路对吗？我在努力减少项目的数量。

Presentation

• Project项目1- Namespaces)

• Project 2-应用层、域层、持久化层(这里的层由文件夹和Namespaces)

• Project 3-Infra

• 项目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

我走得更远。

命令查询分离校长

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

和

不要将ORM实体从rest服务传递到“线上”。

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

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

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

不要这样做。请。它打破了信息隐藏的核心概念，这是实现适当的关注点分离的项目所需要的。相反，您应该有两个不同的对象。您应该有一个表示数据库实体(Orm- Entity )的对象(Java这是Java对象，而C# -这是Orm属性化对象(较少首选)或FluentMapped Orm-实体)，以及一个传递纯数据的对象("Dto“或"Poco")。您的数据库模块应该是导入Room库的唯一模块。如果任何其他模块导入数据库模块的实现细节，那么您就不是应该隐藏的信息。

这个面包屑变成了“合成根”

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