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