很多团队建模做着做着就会掉进同一个坑：图越画越多、包越建越深，最后谁也说不清模型到底放哪、该从哪开始看。真正让人头疼的往往不是Enterprise Architect不好用，而是分层口径没先定下来，包结构也没收敛到一套固定骨架，命名和复用各做各的，时间一长就自然变乱。把分层先跑通，把包结构当成团队规则固化下来，后面不管扩需求、开评审还是出报表，Enterprise Architect建模都会顺很多。

　　一、‌Enterprise Architect建模怎么做分层

　　做Enterprise Architect建模分层时，建议先把看的人和用的场景拆开：业务同学要的是对象、流程和边界，架构同学要的是模块责任与接口方向，开发同学要的是可落地的结构和约束。

　　1、先把分层目标写清楚再选图

　　（1）先明确Enterprise Architect建模这次主要服务谁，是为了需求评审、开发对齐，还是为了交付归档，目标不同分层颗粒度就不一样；

　　（2）再按目标选图种，业务层更偏用例与业务流程，逻辑层更偏组件与接口，物理层更偏部署与节点，让每层只承接一种讨论方向；

　　（3）团队如果总在争论图要画多细，可以直接定一条“到哪个层就停”的规则，比如业务层不写数据库表名，物理层不讨论业务名词，争议会立刻少一半。

　　2、用上层稳定下层可变把复杂度压住

　　（1）业务层先把术语、角色、边界场景定稳，宁可慢一点也不要频繁改，因为上层一乱，下层所有图都会跟着返工；

　　（2）逻辑层重点把模块责任和依赖方向说清楚，优先把接口与数据流向对齐，后续拆分、替换才有依据；

　　（3）物理层最后再落到部署、线程、存储等实现细节，把怎么实现放在最后，避免过早把实现当成业务事实固定死。

　　3、把复用点提前做成可用的模型资产

　　（1）在Enterprise Architect建模里把公共概念、通用接口、标准枚举整理成复用包，别每个项目复制粘贴一份，后期维护会越来越痛；

　　（2）跨图反复出现的说明，尽量用统一的Notes模板或Tagged Values承载，口径一致了，图的阅读成本也会降；

　　（3）同一模块如果在不同层被反复画了一遍，优先回头调整分层边界而不是继续加图，否则模型会越滚越大，最后像雪球一样停不下来。

　　二、Enterprise Architect建模包结构怎么避免混乱

　　Enterprise Architect建模包结构一旦乱，通常会出现三类典型症状：同名包到处都是、图在A包但元素在B包、关系跨包乱连导致追溯困难。要把包结构拉回可控状态，重点不是“集中整理一次”，而是从一开始就让包结构能引导团队按同一套路存放内容，形成默认行为。

　　1、先把根目录骨架固定再允许项目扩展

　　（1）在Model根下先固定几类顶层包，比如业务视图、逻辑视图、物理视图、复用资产、交付导出区，让新人一进来就知道往哪放；

　　（2）每个顶层包下再按系统、子系统或产品线划分，避免按个人习惯随手新建一堆临时包；

　　（3）确实需要项目定制时，只允许在约定的项目扩展区加内容，不要把临时包插进主骨架里，插一次就会带来一串模仿。

　　2、把元素归属和图所在包强绑定

　　（1）约定图必须放在对应元素所属的包内，别出现图在A包、元素在B包，这种结构一旦多了，后续追溯会很痛苦；

　　（2）新建元素时尽量先在Browser里选中目标包再建，减少元素被默认丢到错误位置；

　　（3）迁移时不要只拖动图形外观，要把元素本体移动到目标包，并同步检查引用关系是否仍指向正确对象。

　　3、用命名规则把包深度和重复命名管住

　　（1）包命名建议用层级前缀加领域或模块加用途这种可读结构，让业务层、接口层、部署层一眼能分；

　　（2）同名包尽量不要跨层重复，如果一定要重复，就用前缀硬区分，比如同一模块在不同层的包必须带层级标识；

　　（3）包深度建议设一个硬上限，超过就要求合并或重构，不然Enterprise Architect建模会越来越像迷宫，新人进来基本靠猜。

　　4、用基线与差异对比把整理变成日常动作

　　（1）每次结构调整前先做基线或导出快照，避免误删后找不回，也方便回滚；

　　（2）每周或每个迭代做一次包结构差异检查，重点盯新增顶层包、跨层乱放、重复命名这三类高频问题；

　　（3）发现混乱不要只靠口头提醒，直接把规则写进团队建模检查清单，评审时按清单过一遍，执行力会更稳。

　　三、Enterprise Architect分层与包结构怎么做评审与交付

　　分层和包结构就算搭得再漂亮，如果评审讲不清、交付导不出、复用找不到，Enterprise Architect建模还是会退回到“只在个人电脑里好用”。把评审路径和交付动作也纳入同一套口径，模型才会越做越稳定，而不是每换一批人就重新乱一次。

　　1、把评审路径固定成从上到下的顺序

　　（1）评审先从业务层走一遍术语和边界，先确认大家讨论的是同一件事，避免一开始就陷入实现细节争论；

　　（2）再切到逻辑层对齐模块责任与接口，重点看依赖方向是否合理、是否存在循环依赖、是否有边界不清的灰区；

　　（3）最后到物理层确认部署与非功能约束，把性能、资源、隔离等问题放在该讨论的层级里解决。

　　2、把交付范围做成可导出的入口包

　　（1）建立一个交付入口包，把本次要交付的图、关键元素、说明文档按顺序挂进去，后续导出就从同一个入口走；

　　（2）交付入口包只引用稳定内容，草稿图和试验模型不要混入，避免导出时把噪音一起带出去；

　　（3）每次交付记录入口包路径、使用的模板版本与导出选项，下一次就能按同一口径复现。

　　3、把规则沉淀成可执行的检查项

　　（1）把分层边界、包结构骨架、命名规则、元素归属写成可勾选的检查清单，评审时逐条确认，避免靠记忆执行；

　　（2）对高频问题设红线，比如新增顶层包必须说明理由、跨层引用必须走评审、重复命名必须整改，规则要能落地才算规则；

　　（3）团队规模变大后，用清单和入口包约束新人习惯，比反复口头纠正更省成本，也更不容易产生情绪对抗。

　　总结

　　Enterprise Architect建模怎么做分层，Enterprise Architect建模包结构怎么避免混乱，落地时抓住三件事就够了：先用分层把问题拆开，再用包结构把内容收拢，最后用评审与交付把口径固化。分层让Enterprise Architect建模讲得清，包结构让模型找得到，评审与交付让成果复用得起来，模型自然就不会越做越乱。