我们的技术总监Andrey Kopylov告诉我们AREALIDEA Web开发团队使用哪种方法来设计应用程序体系结构，KISS Architecture本身的开发是如此出色。
设计应用程序体系结构有很多方法。 MVC，DDD，清洁架构等。
MVC非常适合小型应用程序。 当您尝试扩展时，MVC变成了IT世界中最常见的体系结构-Big Lump of Dirt 。
DDD是一种出色的体系结构，但没人能理解。 除非创作者本人和几个建筑师。 该体系结构的目的是使每个开发人员都可以理解它。
干净的体系结构是很棒的体系结构，但是其完整的实现对于大型应用程序是有意义的。 对于中小型企业，在我看来似乎太复杂了。
在这种背景下，当前趋势-向服务和微服务的过渡-Clean Architecture变得过于沉重。
看来，接下来，让我们将MVC用于微服务并停止它。 但是不，这样的自行车不适合我们。
组成部分
我们机构中用于项目的自行车是由来自不同建筑方法的零配件组装而成。
以下是创建易于理解和方便的结构所需的组件：
层数
路由器
路由器负责路由请求。 路由器的大小及其编号间接指示您的应用程序的大小。 对于大型单片应用程序，可以有多个路由器层。
路由器存在于任何体系结构中，但通常是隐式的。 而且由于显而易见的要比隐含的要好，因此值得将其淘汰-使它成为体系结构的组成部分。
控制者
控制器是路由器和服务之间的一层。 控制器中应该没有业务逻辑。
每个控制器仅控制一个实体。 如果需要更多实体，则需要添加另一个控制器。
控制器的数量和大小间接指示应用程序的大小。 控制器下的垂直层可以分为单独的微服务。
观看次数
视图与控制器位于同一层，负责数据的最终显示。 控制器从服务接收数据后，将数据传输到视图并返回视图以供显示。
在极端情况下，View是JSON，XML和类似格式。
服务项目
只有服务可以包含业务逻辑。 服务通常仅指一种模型。 一个服务可以调用另一个服务。
服务层分为命令和查询（命令和查询）。 这是CQRS的标准方法。
一种服务仅执行一项功能。 可以有任意数量的私有功能，只有一个公共功能。 服务的名称以动词开头。 示例：GetUsers，GetPostById，UpdateUser，PublishPost。 服务的名称暗示了功能的正确分离。
在查询中，我们放置不修改数据库的服务。 查询包含一个公共获取函数。 在命令中，我们放置了更改数据库的服务。 命令包含一个公共执行功能。
型号
该模型仅包含与读取和保存数据相关的最简单的逻辑。 此外，这些操作可能与数据库无关。
如果模型与数据库一起使用，则一个模型仅服务一个或几个表。
菜谱
微服务
以我的理解，微服务应仅管理一个实体。 因此，最简单的微服务的架构如下所示：
- 一台路由器；
- 一个控制器；
- 多种观点；
- 多项服务；
- 一种模式。
服务专区
服务是一个小型应用程序。 它包含：
- 一台路由器；
- 几个控制器；
- 多种观点；
- 多项服务；
- 几种模型。
整体式
Monolith是一个很好的应用程序。 没有人喜欢巨石，因为它们的怪异。 如果遵循“整体”优先方法，则可以证明整体是合理的。 在这种状态下，您的应用程序可以保留相当长的时间。
整体包含：
- 一台超级路由器；
- 几个普通路由器；
- 许多控制器；
- 许多观点，许多服务；
- 许多型号。
它开始看起来有点吓人。 在这里，您可以清楚地看到各层的其他垂直间隔。 这样可以使应用程序保持尚未管理和维护的状态。 将整块锯切成零件变成纯机械任务。
为了保持建筑的和谐，您需要：
- 添加一个将解析全局路径的顶级路由器-SuperRouter。
- 按模块按结构分发文件。 也就是说，按照将来切成个人服务。
测试中
在所考虑的架构的框架内，只有服务才经过严格的测试-只有业务逻辑才被嵌入其中。 而且您只需要弄湿模型。
如果您希望测试服务以外的其他东西，那么逻辑的位置可能选择不正确。
结论
我认为，KISS Architecture适用于80％的项目，并且可以使项目顺利进行。
这种架构方法对所有开发人员都是清楚的，并且对于其实际应用而言，您无需阅读有关DDD的丰富书籍。