如何将与内部应用程序紧密耦合的外部应用程序的业务逻辑放在何处，以及如何调整体系结构？
我和一位同事与我们的老板就我们目前正在开发的应用程序的架构进行了相当奇怪的讨论。现有体系结构的C4 (第二级)图如下：
亮点：
- 外部应用程序和内部应用程序之间的共享数据库
- 内部开发是在.NET框架中开发的(开发团队希望少开发其中的一部分)
- 外部开发是使用.NET核心开发的(开发团队希望开发更多的)
- 内部应用程序使用的是数据库优先方法(开发团队希望减少其中的开发)
- 内部应用程序使用的是首先使用数据库的方法，要更改为先编写代码。
由于各种问题，我已经开始了关于稍微改变这个架构的讨论：
- 安全性(由DMZ应用程序在内部数据库中建立的连接)
- 与外部应用程序相关的开发经常在内部进行，因为“我们有所有相关数据。”
- 共享数据库使部署变得更加困难和危险(外部应用程序在数百个内部应用程序表中有几个表)
我提议的架构如下：
- 外部应用程序有它的数据库(更安全)
- 任何主要依赖于外部应用程序业务实体的开发都应该在外部API中完成。
- 内部应用程序可以通过外部API调用获取数据。
我们收到了对我们的建议的下列反驳：
- 由于外部应用程序基本上是内部应用程序的一个模块，所以使用共享数据库更方便。这样就可以在内部代码库中编写外部应用程序业务逻辑(由内部应用程序使用)。
- 如果我们想在其他地方拥有与外部应用程序相关的业务逻辑，我们应该有一个单独的内部API。
在这种情况下，架构应该是这样的：
这个建议对我们来说很奇怪，因为它需要一个额外的应用程序(另一个管道，更复杂的部署)，而不是依赖现有的API。这让我想知道，将业务逻辑放在与外部API业务实体相关的适当位置是什么？
问:如何放置与内部应用程序紧密耦合的外部应用程序(模块)的业务逻辑，以及如何调整体系结构？
回答 1
Software Engineering用户
发布于 2020-07-26 17:36:50
在这种情况下，制作两个API可能会在业务逻辑应该存在的地方造成一些混乱。对我来说，如果可能的话，我会避免使用两个API。
如果有特定于公司的SOP或客户要求有单独的API，那么我将使用内部网络API来拥有所有的基本/核心业务逻辑，以及外部网络API作为内部API请求的实现。维护可能成为一个问题，因为您需要在两个API中匹配类。您可能会遇到一些不具有更频繁更改的相同原因的事情的可能组。
在外部网络上使用现有的API并将其转移到内部网络将更有益处。这将使您可以选择将所有或几乎全部业务逻辑放在一个组件中，而不是通过多个组件链接在一起。它可以是几乎所有的，因为可能存在一些特定于UI/App的业务逻辑。
就适应架构而言，除了将API从外部移到内部之外，外部SPA、现在的内部API和内部应用程序都需要定义API键。键将是/有一些标识符来确定请求的应用程序是内部的还是外部的。在API中，您可以使用键来确定请求对于调用应用程序是否有效。
这里只是一个过于简化的概念：
https://softwareengineering.stackexchange.com/questions/413105
复制相似问题
腾讯云开发者
