架构描述的是在更高层次将应用拆分为子系统或模块的方法，以及这些子系统之间的交互关系。在一个基于微服务架构构建的应用中，每个服务都需要有自己的架构。
事实上，单体应用在复杂度较低时，它的生产效率是要高于微服务的。只有在复杂度逐渐增加，它的劣势才慢慢显现并导致生产效率下降。因此在评价单体应用和微服务架构的好坏时，我们要辩证地评价。
我们做的应用都是要满足用户的需求的。在业界喜欢用MVP最小可用产品来验证用户的需求。这一阶段成本和交付时间是最主要的考量因素。以便获得用户的反馈来迭代开发产品。在这种背景下，无疑单体应用是最合适的，单体应用开发简单，只需要构建一个单独的应用程序，其次，测试也不麻烦，只需要测试端到端的场景和调用接口的测试；部署也简单，只需要将应用整体打包好上传到服务器即可，没有过多的依赖。我们在做单体应用时，也可以通过模块化设计来保持部分逻辑的重用。在单体应用内部设计好相应的模块，包括对外的接口、数据存储。方便日后向其他架构模式迁移。
当系统壮大后，各方面的复杂度都在增加，就是时候对单体应用的体系进行拆解，典型的手法就是分层。这种分层遵循上层使用下层的定义的服务，下层对上层隐藏自己的实现细节。分层在一定程序提供了解耦的能力，层与层之间的依赖程度有效地降低了。分层的数量要适合，过多反而会影响性能，因为数据在每一层传递时都会被封装成对应的格式。有时上层修改时，会引起级联修改。
典型的两层结构：客户端/服务端。对于简单的应用来说两层没有太大的问题，如果业务变得复杂了，将业务写到哪一层都不太合适。
那么引入一个中间层，我们将它称为领域层或业务逻辑层，把复杂的业务逻辑写在这一层。三层的结构就变成了展示层，业务逻辑层、数据访问层。展示层就是我们的前端，业务逻辑层和数据访问层就是我们的后端。 或许大家已经听过前后端分离，因此三层还可以是这样的：接口层、业务逻辑层、数据访问层。这三层都是后端的，前端就通过接口层与后端交互。
