关于这几个对象的区别，请参考《HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-上篇》中有描述鲁棒图的基本用法说明。后续本文将直接使用不再复述具体的用法。
大家看完鲁棒图发现鲁棒图也有实体、控制及边界对象，怎么这么类似web系统时用到的MVC模式，那么我们这里对比下这2个模式的异同点:
通过上面的对比我们发现，鲁棒图能够更全面的体现架构设计过程中涉及的内容，单独的架构模式更侧重其中的部分架构层次，比如逻辑架构采取MVC的模式。
2.2、高层分割（概念架构形成的具体操作方法）1）、直接分层
2）、先划分为子系统，再针对每个子系统分层
针对高层分割，我们可以采取分阶段的模式来进行落地实践：
1、直接划分层次：直接把系统划分为多个层次，梳理清晰各层次间的关联关系
2、分为2个阶段：先划分为多个子系统，然后再梳理子系统的层次，梳理清晰没格子系统的层次关系
针对分层模式的引入，这里分享几类划分模式及方法：
1、逻辑层：逻辑层，上层使用下层观念；不关注物理划分，也不关注通用性
2、物理层：分布部署在不同机器上
3、通用性分层：通用性越多，所处层次越靠下
Layer：逻辑层，上层使用下层观念；不关注物理划分，也不关注通用性。Layer是逻辑上组织代码的形式。比如逻辑分层中表现层，服务层，业务层，领域层，他们是软件功能来划分的。并不指代部署在那台具体的服务器上或者，物理位置。
多层Layer架构模式
诸如我们常见的三层架构模式，三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
逻辑层次的架构能帮助我们解决逻辑耦合，达到灵活配置，迁移。 一个良好的逻辑分层可以带来：
A、逻辑组织代码/代码逻辑的清晰度
B、易于维护（可维护性）
C、代码更好的重用（可重用性）