项目架构的最佳实践.服务器端

Question

通常(我熟悉的)划分服务器端的方法是n层体系结构：

1. 数据访问层，通常有实体和上下文(可能还包括一个存储库)。
2. 业务逻辑层
3. 合同-接口
4. 服务-实现接口的类(可以是用于E.G的Web )

当然，我也不想讨论n层体系结构。

最近，我看到越来越多的“模块”架构，我想知道它(我不熟悉这个架构的专业术语)

其中，每个模块不是数据库中的表，而是一组具有共享概念的表。

看起来是这样的：

是否有任何已知的良好架构可以将各层按服务器端的模块分开？如果是的话，这种体系结构的专业术语是什么?这些体系结构的优缺点是什么？

Answer 1

是否有任何已知的良好架构可以将各层按服务器端的模块分开？

模块和层是两个不同的概念。层通常用于描述在环境中部署代码的方式。然而，模块是根据功能组织代码的。模块还有其他的视角，可以根据项目需求、发布顺序等进行分析。其底线是模块是解决方案布局中的代码组织机制。

这种体系结构的专业术语是什么?这些体系结构的优缺点是什么？

我不知道在图像中显示的代码组织的专业术语。不过，让我表达一下我对这幅图像的看法。它只是解决方案中的一种代码组织技术。这和建筑没什么关系。同意，代码组织是架构的一部分。但是，还不确定是否有这样的术语。我对这样一个代码组织的看法是

• 该项目更多地关注指示富域的代码的功能组织。团队中的人对领域有更好的理解。因此，团队可能会发现这个组织更自然。
• 这种类型的代码组织的缺点是许多C#项目。不是基于模块为所有契约和子文件夹创建一个项目，而是为每个功能创建项目，这些项目稍后会被缝合在一起。
• 我可以看到的另一个缺点是，涉及到的许多程序集可能会拖累您的性能。

希望这能有所帮助。