i have a few questions regarding monolith and n layer architecture.
First, whats the difference between Monolith and n Layer architecture?
Second, let's say I have a single Visual Studio solutions that consist of multiple projects such as:
Is that considered as Monolith or n layer architecture?
If I have microservices that consist (let's say) 3 Web API and I build each service in single separate Visual Studio solutions, it is ok to implement my previous project structure (service layer, business layer, data layer, etc)?
Thank you very much and sorry for my bad english.
答案 0 :(得分：11)
好的，所以Monolith解决方案是在单一解决方案中基本拥有一个项目的旧方法，其中包含所有代码。
所以我们假设你正在做一个网站。
这意味着您将使用单个Project和所有数据库调用（持久性），逻辑（业务逻辑/服务）创建单个解决方案，并最终确定如何显示计算出的数据（表示）全部混合在一起这个单一项目的混乱方式。有时人们试图将问题分成文件夹，但通常情况下这是一个很大的混乱。这使得应用程序的支持/维护成为一场噩梦。如果您希望对网站/应用程序进行一次更改，整个应用程序将脱机/重新启动。
VS
n-tier / n-layered解决方案/应用程序。这就是我们在一个解决方案中有多个项目（通常）的地方，它将我们的应用程序的关注点分成更小的组件。这使我们能够将问题空间保持在一个区域，使其更易于维护和支持。这样，您可以更轻松地重复使用各种组件/项目/ dll，进入应用程序的各种其他子系统。它比旧的整体架构模式更好。但是，如果您希望对网站/应用程序进行一次更改，整个应用程序仍将脱机/重新启动。
最后，我们有microservices。这是一个更现代的概念，并继续monolith -> n tier -> microservices的演变。这时我们将应用程序问题分解为单个应用程序，以便在需要更新一个微服务时，整个应用程序没有停止。当然，依赖于微服务的应用程序的部分可能会停止/受到影响，但整个应用程序可能不会。
让我们举个例子：
我有一个销售宠物（猫/狗/等）的网站。 我可能将这个网站拆分成单独的微服务迷你网站：
因此，每个网站都是一个网站，就像n层架构的应用程序一样。所以它会有一个表示层（MVC网站）。一些数据库项目和一些基本服务。
现在，4个微服务（迷你网站）中的每一个都是这样做的。
现在，您需要使用网站的管理部分更新一些内容。你离线，主网站保持不变。人们仍然可以浏览和购买动物。
所以是的，如果你的应用程序足够大以至于你可能想要分割区域，那么实现微服务是一件好事。它确实增加了一些复杂性，但它也带来了它自身的优势。
是的，如果您的应用程序不是一些愚蠢的hello-world应用程序或某些研究项目，那么您的微服务应该遵循n层模式。
答案 1 :(得分：0)
您的问题的简短答案是- 技术堆栈的水平分区（n层体系结构） 与 技术堆栈（微服务）的垂直分区