我正在尝试在 asp.net 项目中实现模块化设计，将应用程序划分为不同的模块，如 HR、库存管理系统等。由于我试图保持不同的模块相互独立，因此我将这些模块分开，使每个模块模块是一个单独的 Visual Studio 解决方案，具有 UI、BLL、DAL 甚至是单独的数据库架构。
到目前为止，我认为这是开发管理系统和 ERP 的一种常见做法，但我在网上搜索了过去三天，但几乎没有找到任何有关开发模块化应用程序的完整内容。我发现的大部分只是解释内聚和耦合概念的理论，而不是现实世界的场景。所以我想知道
任何想法，链接都受到热烈欢迎。
这是个人观点，值得商榷。
我将这些模块分开，使每个模块都是一个单独的 Visual Studio 解决方案，具有 UI、BLL、DAL 甚至一个单独的数据库模式。
听起来完全是矫枉过正。抽象之上的抽象使您的应用程序难以维护、支持和增强。您需要将模块分成单独的解决方案吗？
这是分离模块的正确方法吗？
不，我认为这完全是过度设计。我建议使用项目来分隔模块。而不是单独的解决方案。解决方案的问题是它需要外部依赖管理工具，这需要大量的精力来引入和后期维护。
现实世界的模块化应用程序是如何开发的？
使用抽象（接口和抽象类）和单独的项目。
不同的模块应该如何相互通信，但它们又保持相互独立。
通过使用接口、DI、IOC、TDD
我认为应该有一个使用这些模块的核心应用程序，核心应用程序应该如何与这些模块通信？
Core不与模块通信。事实上，理想情况下它不应该依赖于任何其他项目/库。这使得在大型解决方案中引用和使用变得简单。
每个模块都有一些数据，实体，对象是通用的，我应该将它们放在核心模块中以便其他模块使用它们（我认为这将使模块耦合到核心）还是每个模块都保持自己的数据副本 + 定义那些对象，（我认为这会破坏 DRY）
我强烈建议使用Core项目中的单个副本。有关原因的详细信息，请参阅此问题。
这是大部分完全主观的主题之一，但您可能希望考虑 SOA（面向服务的体系结构）。
使用 SOA，您可以为每个业务领域定义一个服务（对于这个示例，我将坚持使用 Web 服务，尽管根据要求存在其他服务类型）——HR Web 服务、项目 Web 服务、财务 Web 服务和等等。
然后，您可以将所有这些与将与这些服务通信并使用这些服务的前端系统结合在一起，这通常是您的核心应用程序，但根据您的需要和要求，您可以选择多个前端系统。
对于前端系统，我建议使用具有区域概念的 ASP.NET MVC，它可以让您将前端分成特定区域 - 人力资源区域、项目区域、财务区域等，其中包含模型和每个特定区域的视图。
这样做将使您以模块化方式构建，您可以构建您的第一个 Web 服务，例如 HR Web 服务，它具有获取相关 HR 数据等的方法，然后构建 MVC 应用程序的 HR 区域。然后扩展只依赖于构建 Web 服务，并在 MVC 应用程序中创建前端。如果需要财务信息，人力资源领域就可以访问财务网络服务，但它仍然将所有内容保存在不同的独立模块中。
使用这种方法也有助于促进未来的互操作性——公司中的其他系统可能会发现与某些 Web 服务交互很有用。例如，在以前的角色中，公司工程软件与项目团队 Web 服务集成是很有用的，因为它允许将工程相关信息链接到其相关项目。
如果系统在资源需求方面增长，它也应该是相当可扩展的，因为如果它开始消耗大量系统资源，将项目 Web 服务卸载到另一个服务是微不足道的。它还允许您在需要时切换模块 - 如果您决定迁移到 Linux/Java 平台，您可以通过逐个模块移植来轻松迁移，而不会真正中断整个系统。
但是，当然，正如我所说，这只是一种这样的选择，很大程度上取决于您的具体情况。
现在回答为时已晚，但似乎很有趣。
由于我试图使不同的模块相互独立，因此我将这些模块分开，使每个模块都是一个单独的 Visual Studio 解决方案，具有 UI、BLL、DAL 甚至一个单独的数据库模式。
这取决于您的应用规模。如果您创建了一个非常简单且功能很少的应用程序，那么使用组合程序集是安全的。或者，如果您愿意，只需将 UI 与其他模块分开即可。至少它可以帮助你强调SOC。请记住，加载多个程序集可能比单个程序集慢。
这是分离模块的正确方法吗？
模块分离总是有一个缺点，它需要映射。这通常意味着性能较慢（可能可以忽略不计，但仍然存在），以及较慢的开发时间。如果您的应用程序足够大且足够复杂，那么这是值得的，因为您可以为每个模块创建模块化单元测试。
现实世界的模块化应用程序是如何开发的？
虽然没有确切的实践，但每个问题都需要解决方案。对于简单的计算器应用程序，您不需要繁重的多线程或依赖注入架构。
不同的模块应该如何相互通信，但它们又保持相互独立。
使用界面。您可以稍后使实现有所不同。例如，您当前为您的应用程序使用 C# Winform，使用接口与 BLL 通信。稍后，您想迁移到 ASP.Net，那么您只需更改实现，但保持与 BLL 通信的接口不变。
我认为应该有一个使用这些模块的核心应用程序，核心应用程序应该如何与这些模块通信？
每个模块都有一些数据，实体，对象是通用的，我应该将它们放在核心模块中以便其他模块使用它们（我认为这将使模块耦合到核心）还是每个模块都保持自己的数据副本 + 定义那些对象，（我认为这会破坏 DRY）
我假设它是一个企业级应用程序，它共享相同的模块/数据，例如员工。如果真的需要统一表现，那么您应该在核心级别提供非常基本的逻辑。在应用程序/实现级别，您可能有不同的实现来满足每个要求。
不要强制将所有业务逻辑统一到核心。如果特定应用程序需要不同的实现，则很难使核心可配置。