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