您可以谈论很多有关应用程序体系结构，SOLID，OOP原理，分层或洋葱等体系结构模式的信息。 设计模式。 在我的整个经历中，我意识到有多少人有这么多意见。 当您是一名初学者程序员时，您会抱有很大的野心，在资格方面会有所成长，您会感觉自己知道一切，对您所做的一切都是``不好的''，而且您肯定会做得更好...但是岁月流逝，所获得的经验表明情况恰恰相反。 在切入点之下，我将尝试简单地（最重要的是，简单地说）告诉您有关良好体系结构的信息。 至少是可扩展且受支持的，有关详细信息，我要求一只猫……
首先，要创建一个好的项目架构，您需要确定其功能：
- 必须支持该体系结构。
- 系统可扩展性，无需拐杖。
- 设置的灵活性，许多任务必须在不更改程序代码的情况下解决。
- 体系结构的可靠性。
第一点是遵循SOLID原则（当然，基本上是“责任唯一性”原则）来解决支持的难点，因此您需要选择基于微服务的架构或单片核心系统的模块化架构。 这些方法之间没有根本区别。 对于我正在从事的项目，我选择了第二种方法，即模块。
第二点可以使用事件观察者或调度程序编程模式来解决，它们彼此相似，因此我们将不再关注这一点。 他们工作的本质是从当前正在执行的模块中抛出一些消息，并在必要时侦听需要与此对象一起工作的模块。
第三段也很简单地解决了实体的描述部分，即与实体本身分开存储的实体的属性。 这是对EAV（实体属性值）的引用，您不必为业务逻辑处理实体的所有字段，某些属性承载信息量，其他属性用于排序和过滤，而仅一部分用于构建业务逻辑。 因此，如果实体存储为EAV，我们可以随时添加或删除不需要的属性。
我们要求的第四点是可靠性，这意味着最少的“拐杖”和更多的自动化。 大多数Web应用程序由数据显示界面，表格，过滤器，排序，实体卡组成。 以及数据输入接口，表格。 因此，值得使用表格工厂，表格工厂，卡片工厂。 更高的自动化程度，最后我们可以从表示领域进行抽象，并专注于业务逻辑和实质性任务...
因此，结论本身表明，为了构建良好的体系结构，有必要进行抽象，确定技术和编程模式并为开始开发奠定基础...
现在我们已经制定了一个计划，确定了需求，然后我们需要决定如何构建体系结构。 实际上，我不了解所有这些分层的体系结构或洋葱。 我从他们那里得到了一些东西，然后自己发明了一些东西，如果人们只是理解它的含义，我什么也看不到。 实际上，整个体系结构可以归结为简单的步骤：
- 基础是抽象（抽象类和接口，这些类和接口定义了将系统的各个组件组合成模块的协定）
- 接下来，我有一个内核层来运行模块并对其进行管理。
- 加载布局系统
- 启动模块后，每个模块作为一个单独的微服务
但是，什么使体系结构良好？ 这个问题并不简单，但是如果一切都简化到哲学推理的水平，那么这个问题就会得到回答。 应用程序启动后。 我们有隔离的零件，模块。 每个模块仅负责一个系统功能。 我们介绍了设计为MVC应用程序的每个模块，并具有视图，控制器，模型。 模块的每个部分还负责其每个动作。 我们进行更深入的研究，我们将看到该视图还具有某些部分，这些部分是工厂类和布局的扩展。 实际上，布局也是一个模块，它首先被加载，所有其他模块对其进行补充，并构建一个接口（或输出系统）。 但是，您如何降低所有这些依赖性呢？ 对于观察者来说答案是显而易见的，对于他们抛出事件的布局块的每个渲染，您只需要侦听此事件，在应用程序中观察者，并在各层中添加必要的块更新，并获得适当的输出即可。 许多模块还具有自己的事件，其他模块可以订阅这些事件，并能够添加/或更新传输集中的数据。 所有这些导致了这样一个事实，即在应用程序中，模块之间几乎没有连接，并且可以彼此独立地使用。
鉴于上述情况，出现了一个合理的问题：如果一个模块侦听另一个模块，则必须为这些模块配备某种依赖管理系统。 也就是说，另一个模块所依赖的模块，我们必须首先开始，而另一个模块所依赖的，我们必须之后运行。 这样就产生了一种简单的依赖关系实现方式，我们创建了一个用于启动模块的队列，并对其进行简单排序，以使所有其他模块所依赖的模块都首先在加载内核之后加载。
最后，我可以说以下。 好的架构并不是要解决的艰巨而长期的任务。 最后，它有助于更有效地花费资源和时间。 毕竟，更改控制面板中的设置需要花费五分钟。 编写两行用于添加的时间也不是很多。 但是，得出一个结论，每个人都必须进行反向操作，调试大量数据已经比开发体系结构构建策略所需的时间长很多倍。