对于上下文的识别，没有可遵循的标准可走，从不同的角度切入将会识别到不同的上下文，可从张逸老师的领域驱动设计实践中窥之一二，以业务复杂度、管理复杂度和技术复杂度出发，面对这三个角度去依次分析，从业务视角、工作视角、应用视角去识别，进而识别出准确的上下文，通过不断的分析斟酌考虑，逐渐识别出符合当前预期的上下文，如在实际操作环节发觉当前上下文的设计显得不那么合理，还可再进行变动、拆分上下文。
但需注意的一个是，我们识别上下文的目的是什么，是为了控制上下文，准确的说是为了控制上下文的边界、大小，是为了保住我们所守护的上下文不会因过度成长变大而奔溃，亦或因上下文过度缩减而失去价值，保证上下文内一切的稳定，上下文与上下文间交互的可用性，也或者是当我们退出上下文时，交付出来的上下文是非常可观的，而不是一个烂摊子。
上下文映射规划了这么多限界上下文，该如何穿针引线将这些上下文串起来便是一个问题了，用例场景的完整实现往往是由多个上下文的协作完成的，怎么去组织这些上下文，领域驱动设计提到的几种方式及软件工程中常用模式。
合作关系：一荣俱荣，一损俱损。
共享内核：上下文间共享领域实体。
客户方-供应方：下游客户依赖于上游供应方。
遵奉者：下游客户顺应上游供应方。
各行其道：没有关系的关系，相互隔离。
防腐层：在下游上下文与上游间增加一道屏障，以此来隔绝与上游的直接交互保护下游。
开放主机服务：在上游与下游上下文间增加一道协议，以此来规范下游对上游的集成。
已发布语言：发布方上下文发布一份包含丰富文档的信息交换语言，消费方上下文翻译并使用。
这些模式其本质是为了协作，为了满足用例场景下对多个限界上下文的调用，通过上下文映射图，可以清楚知晓运行逻辑。为了实现上下文映射，简单讲就是如何将两个上下文连贯起来，常借助的方式是诸如 RPC、HTTP、消息队列等，依照上下文间映射类型，挑选一件趁手的工具。
我们通常喜欢对各种事情归纳总结，如文章的层次分明，如建筑结构高低有序、疏密有致，给人一种各处所关注的信息视角不同，而组合起来显得如此美妙。软件中同样运用着分层来隔离关注点，以此来隔离每层的演进速率。
当我们考虑限界上下文时，不仅需要去考虑其内部的领域设计，还得从其应用边界本身考虑，限界上下文是属于架构设计层次，主要针对的是后端架构层次的垂直切分，按照经典 DDD 的分层结构来看，共分为如下四层：
User Interface 为用户界面层，向用户展示信息和传入用户命令。这里指的用户不单单只使用用户界面的人，也可能是外部系统，诸如用例中的参与者。
Application 为应用层，用来协调应用的活动，不包含业务逻辑，通过编排领域模型，包括领域对象及领域服务，使它们互相协作。不保留业务对象的状态，但它保有应用任务的进度状态。
Domain 为领域层，负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的，但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心，领域模型位于这一层。
Infrastructure 为基础实施层，提供公共的基础设施组件，如持久化机制、消息管道的读取写入、文件服务的读取写入、调用邮件服务、对外部系统的调用等等。