如何为具有子产品/模块的产品命名空间？

问：

我仔细阅读了。是的，非常有帮助！

https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-namespaces

假设您有以下产品和命名空间

Microsoft.Dynamics.Inventory     is a DLL
Microsoft.Dynamics.Bank          is a DLL

以上每个都有（视图、报告、实用程序等）

Microsoft.Dynamics.Inventory.DLL

我应该这样做吗？

Microsoft.Dynamics.Inventory.Sales.Reports
Microsoft.Dynamics.Inventory.Sales.Views
Microsoft.Dynamics.Inventory.Sales.Controls

Microsoft.Dynamics.Inventory.Purchase.Reports
Microsoft.Dynamics.Inventory.Purchase.Views
Microsoft.Dynamics.Inventory.Purchase.Controls

或去吗？（目前使用）

Microsoft.Dynamics.Inventory.Reports.Sales
Microsoft.Dynamics.Inventory.Views.Sales
Microsoft.Dynamics.Inventory.Controls.Sales

Microsoft.Dynamics.Inventory.Reports.Purchase
Microsoft.Dynamics.Inventory.Views.Purchase
Microsoft.Dynamics.Inventory.Controls.Purchase

当你写的时候，第一个看起来不错。但是文件夹结构会很糟糕。using directives

1. 如果我使用第二种方法，我得到了非常好的结构化文件夹 见图片
2. 如果我使用第一种方法，每个子模块都有视图、报告、控件（重复）

请不要基于意见。我其实怕一个不好的结构以后会变得更糟。

我无法想象一个例子是不行的？System.Data.SqlClientSystem.SqlClient.Data

通常

System.Data.Common can used bellow
System.Data.OleDb
System.Data.SqlClient
System.Data.AnyProvider

如何将该结构应用于我上面的例子？

笔记

1. A 销售人员可能没有报告（所以第一种方法不好吗？
2. 购买可能没有控件（所以第一种方法不好吗？

我看到在 MVC 架构中，他们采用了第二种方法。我不确定。

https://github.com/cruzerM/erp-bank-net/tree/master/ERP_BANK.Web/Views

那么我应该放弃第二种方法吗？