如前所述,领域驱动设计(DDD)是非常复杂的方法论,不过进行这里的讨论只需要理解DDD中的限界上下文(Bounded Context)
词语的意义是由上下文决定的。例如,“角”这个词语可以出现在讨论几何学的上下文中,也可以出现在零钱的上下文中,分别表示完全不同的意思。在软件开发中,软件工程师使用得驾轻就熟的命名空间也起到了上下文的作用。
DDD的设计者Eric Evans发现,在软件的沟通过程中,软件工程师往往不能理解领域专家(可能是客户)的专业领域,领域专家也看不懂软件设计的相关文档。DDD认为,通过在软件工程师和领域专家之间定义一致的上下文和上下文中的术语,可以保证软件设计者与领域专家的正确交流,以保证软件逻辑正确和架构清晰。限界上下文之间通过仔细定义的接口通信,从而实现低耦合。例如在聊天软件中,可能有一个上下文处理用户登录,另一个上下文处理用户的聊天记录,而这两个上下文都可以定义称为Session的术语:前者中Session指用户的认证信息,后者中的Session指两个用户的聊天进程。
这样就解决了之前横向扩展中代码拆分的问题:每个上下文都可以被安全地拆分出来,并且理由充分:每个上下文往往对应着软件想要解决问题的一个子问题,因此其内部代码也一定是在集中解决这个问题。而且每个上下文向外提供具有领域语义的接口,把上下文作为切分软件的界限,很自然地满足了软件模块化的高聚合低耦合原则。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。