边界
边界本质上是面向对象方法的一个重要概念，与封装的概念师出同源。面向对象里，任何一个对象都有一个边界，外界只能通过这个边界来认识对象，与对象打交道，而对象内部则是一个禁区。
在需求出来之前，必须先设想一个边界，这个边界的大小是不确定的，随着需求的明确，边界也逐渐变得明朗。但是问题是确定需求，依靠参与者和用例；而明确参与者和用例，前提条件是边界是明确的，而偏偏这是边界又是不明确的，所以这就是一个矛盾。实际上需求就是在不断地调整这个矛盾的过程中逐步明确，进而更加确定边界的。这个调整过程，不可避免地会导致参与者和用例的变化。所以需求过程是一个动态的过程，需要迭代的过程，而不是瀑布方法。
边界决定视界
边界是可大可小的，由建模者主观臆定。对于建模来说，同样的需求交给10个不同的人，可能得出10个不同的结果。因为除了对业务的理解不同之外，不同的人选择的边界不同，视角也不同。但那一个更正确呢？只能把这些不同的结果进行对比、思考、讨论，最终希望得到一个恰当的结果，就像盲人摸象一样，多方结果的相互印证得出的结论总是会更接近真相。所以建模过程中，如果对建模结果感到疑惑，就可以试着改变边界设定，得到不同的参与者和用例，再通过相互印证的方式得到更好的结果。
边界决定抽象层次
在建模的时候，如果一个很庞大的系统，信息量之多会超出人脑的处理能力，进而失去分析能力。这就需要很好地把抽象层次，排除掉非本层次之内的信息，自顶向下地把整个系统描述清楚。边界的设定可以帮上大忙。
比如有一个大系统，其涉及的单位包括商业网站、银行、政府机构、工厂、物流、批发商、零售商等，这里面的业务非常复杂。
可以先把边界设定为整个商业过程，得到的参与者是商业网站、银行、政府机构、工厂等，进而得到 商业网站—>宣传商业信息、银行—>管理财务、政府机构—>监管市场、工厂—>生产商品等，这些抽象层次非常高的用例。为这些用例建模、获取领域模型、建立业务架构等工作，确保参与者都能达到其业务目标，整个商业模式得以实现。
再接下来，把边界缩小到宣传商业信息领域，也就是商业网站部分，进而降低了抽象层次，就会得到广告策划人员、平面设计人员、网站管理员等参与者，进而得到策划广告、设计广告、发布广告等用例，而这些粒度小一些的用例保证满足宣传商业信息这一大用例。
如此这般，层层推进，直到抽象层次降低到对象的级别。
灵活使用边界
边界在设计层也能发挥重要的作用。软件设计也面临着很大的信息量，既要实现需求，又要保证性能，要具有扩展能力，还要友好易用。这时设定一些边界就能有效地降低复杂度，比如将实现需求的任务交给分析模型，在这个边界内只考虑需求和实现；将扩展能力交给框架设计，在这个边界内专心设计灵活的框架；然后再在框架的约束下，把分析模型转化成设计模型。