首先，我们应该明确一点，应该基于领域来划分架构的边界，每一篇架构图都是一个独立的领域。那么领域该如何划分呢？架构图又应该包含哪些方面呢？
术语
领域划分、边界
领域他不是部门，比如C端不是一个领域而是一个组织，一个组织可以有很多个领域。举个简单的例子，一个C端的订单详情页，可能需要类似导购、交易、库存、价格、商品、营销多个领域的聚合。一个领域应该是核心的业务问题域，他自身的特点应该是高内聚、边界性强、操作关联性强、有自己的独立实体。
子领域
相对领域而言，子领域的概念可以理解为领域的子集，如交易中正向交易、逆向交易等。
模块
子领域应该由多个模块组成，模块是用户能完成一个业务目标的最小颗粒度的完整功能，比如展示可以购买商品的列表页、购物车、下单等，也可以是一个通用的模块，比如超时取消订单、流程编排等。
架构图
那么说完基本的领域概念和术语，接下来阐述一下架构图的几个分类和画法。
业务架构
业务架构或者说业务领域图，他的作用是来描述功能点和业务流程，受众可以是产品、运营、技术等。
业务架构是根据不能的功能模块来组织其相互之间的关系的，一个产品中不同的功能模块之间的关系分直接关系和间接关系，只有直接关系的功能模块才会被组织到一起形成一个子系统，当有直接关系的功能模块组成一个子系统之后，解决相同问题域的子系统就形成一个功能层级。功能层级按照最接近用户实际操作的距离程度从上到下或者从左到右的划分，就形成了产品架构的分层。
系统架构
系统架构主要用来描述系统由哪些领域和子领域的功能模块组成，一般针对开发人员、构架师、产品等角色。
如果说业务架构、产品架构是站在业务和产品的角度来看待领域和模块的关系，那么系统架构就是站在技术实现的角度按照不同的子领域的功能模块来阐述系统的组成。
子领域架构
以上图举例，针对系统架构层面有正向交易、逆向交易、订单管理、履约4个子领域，如果有必要做到架构设计更详细清晰的话就需要针对子领域做更具体的设计说明。
全景图
每个子领域需要有一个描述整个子领域负责的业务场景的视图，从该子领域的角度出发，包括模块内部的核心模块之间以及外部模块
比如下图：正向交易全景图
关键业务场景图
用来阐述关键的业务主场景
比如：酒店订单场景从用户下单、支付、商家接单、排房、办理入住、离店的主要场景描述
关键路径流程图
用来反馈模块之间的交互，可以用时序图来表示。
举个简化版下单流程
部署图
如无太大必要，可以忽略