是.net项目体系结构按域功能划分是一个很好的、可行的实践

Question

我正在实现由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

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

然而，当存在循环依赖关系而第一种方法没有时，这种方法可能会导致问题。例如，当User的属性类型为Bookmark, Bookmark的属性类型为User时，
此外，实际上功能确实相互依赖，这些"边界"可能相当模糊。
也许，还有其他的缺点，我没有看到，这将成为未来架构的缺陷。

第二个项目组织是否可行?
人们会使用第二种方法吗?

Answer 1

您最后一次想一次看到所有的枚举、所有的存储库、所有的模型是什么时候?这种情况几乎从未发生过。更常见的是想要完整地检查一个特定的特征。

用一些任意的标准聚类代码是一个常见的错误，而这些标准实际上并不是用来查找的。

按照你想要搜索的东西来聚类你的代码。这里，使用基于特征的分类。

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

例如，当User有一个Bookmark类型的属性，而Bookmark有一个User类型的属性。而且，实际上功能确实是相互依赖的，这些"边界"可能相当模糊。

如果你有这个问题，这是一个信号，这不是一个很好的分割边界。也许你根本不需要分开?将代码拆分为不同的项目有成本也有好处。你需要对双方都有一个清晰的理解。分成几个项目对你有什么好处?名称空间和文件夹难道不会达到几乎相同的目的吗?(我不知道你的答案。)