按域功能划分的.NET项目体系结构是否是一种良好且可行的做法？

我正在实现由SOA WCF微服务和ASP.NET MVC web客户端组成的应用程序，无法在以下项目和组织之间进行选择：

1。按层\类型划分

所有项目模型、枚举、服务等都存储在单独的项目中，无论它们属于哪个功能

Solution
+ Domain
++ Models
  - User.cs
  - Payment.cs
  - Bookmark.cs
++ Repository
  - UserRepository.cs
  - PaymentRepository.cs
  - BookmarkRepository.cs
++ Enums
  - UserType.cs
  - PaymentStatus.cs
++ Services
  - IUserService.cs
  - IPaymentService.cs
  - IBookmarkService.cs
  - UserService.cs
  - PaymentService.cs
  - BookmarkService.cs

2。按域功能划分

每个项目都代表一个独立（有时部分依赖）的功能，包括所有必要的模型、存储库、服务、业务逻辑等

Solution
+ Domain
++ Authentication
  - User.cs
  - UserType.cs
  - IUserService.cs
  - UserService.cs
  - UserRepository.cs
++ Payments
  - Payment.cs
  - PaymentStatus.cs
  - IPaymentService.cs
  - PaymentService.cs
  - PaymentRepository.cs
++ Bookmarks
  - Bookmark.cs
  - IBookmarkService.cs
  - BookmarkService.cs  
  - BookmarkRepository.cs

我一直在使用第一种方法，但第二种方法对我来说很好，因为：
-这些目录，如

模型

，

枚举

随着时间的推移会增加到50-100个类，因此变得不方便
-如果您实现的应用程序只能使用一种功能，那么您必须使用所有模型、类型和服务引用整个大型项目
-第二种方法允许您轻松地引入/删除/更改 任何功能
-当按域分隔时，代码看起来更易于重用

但是，当存在循环依赖项而第一种不存在时，这种方法可能会导致问题。例如，当

User

具有

Bookmark

类型的属性时，

Bookmark

具有

User

类型的属性时
此外，实际上功能是相互依赖的，这些“边界”可能非常模糊。
可能还有其他缺点，我看不到，这将成为未来的架构缺陷

第二个项目组织可行吗？

---

人们会使用第二种方法吗？

上次您希望同时查看所有枚举、所有存储库和所有模型是什么时候？这几乎从未发生过。更常见的情况是，需要全面检查特定功能

根据一些没有实际用于查找内容的任意标准对代码进行聚类是一个常见的错误

根据要搜索的内容对代码进行聚类。这里，使用基于特征的分类

此外，我不认为这是一个品味的问题。将类似代码聚集在一起的唯一原因是优化查找。因此，请选择与您正在搜索的内容相匹配的集群

例如，当用户的属性类型为Bookmark，而Bookmark的属性类型为User时。而且，实际上功能是相互依赖的，这些“边界”可能非常模糊

---

如果你有这个问题，这表明这不是一个好的分割边界。也许你根本不需要分手？！将代码拆分为单独的项目具有成本和收益。你需要对双方都有清晰的理解。您将从拆分为项目中获得什么好处？名称空间和文件夹不是实现了几乎相同的功能吗？（我不知道你的问题的答案。）

我认为这归结于观点，甚至可能取决于具体的项目。如果我必须对某些东西发表评论，我认为为枚举单独设置一个项目是很奇怪的，我会将它们与其他模型放在一起。第二种方法。功能文件夹使您更容易理解以下答案中所述的单个功能