我的建筑是什么

我认为"三层架构"这个术语定义不清，已经过时了，因为它既没有突出代码的结构方式，也没有从用户的角度提供任何好处或缺点。问题是，它指的是物理部署，这在虚拟化和分布式计算时代几乎没有意义。

"层"指的是机器，由于您通常只能使用本地开发机器运行和调试网站，因此它通常可以部署为一层。也许，更相关的问题是"我可以将应用程序拆分的（逻辑）机器的最大数量是多少？"这个数字与实际的部署无关，而是由代码的结构——分层决定的。当然，复制另一台机器（用于负载平衡的多个web服务器）的机器不算在内。

这些信息仍然不太相关。这表明您的代码可以分离关注点，并且可能比不允许拆分到不同层的代码更具可扩展性。另一个想法是强解耦：你可以替换一层，而不接触另一层。在实践中，这几乎不起作用（例如，从Oracle切换到MySQL），并解决了一些过时的问题："在表示层更改操作系统只会影响用户界面代码。"（维基百科）

当您添加外部SaaS/PaaS产品或SolR（搜索引擎）等第三方工具时，所有这些都会变得更加不明确。SolR是数据层还是逻辑层的一部分？通过添加缓存层，您的体系结构是否变为4层？如果您的数据库层不是一台机器，而是一个由10台机器组成的集群，该怎么办？

另一方面，MVC指的是代码的结构化方式。然而，这不仅仅是一种表示层模式：模型既不知道控制器，也不知道视图。MVC将数据、表示和逻辑分离到不同的层中。大多数MVC实现使用两步视图作为表示层模式，使用PageController作为控制器模式。FrontController通常也存在，并在委托给相应的PageController之前处理所有请求，但关键是模型并不知道所有这些。

我建议完全放弃"n层架构"的概念。

我将其描述为一个三层应用程序，并将MVC方面放入表示层。

由于您的基本结构是基于三层的，并且使用MVC向用户显示数据。（也许你可以把MVC叠加在表示层和应用层上，来说明这两者之间的实际交互）。