一个领域内可能存在多个子域、多个限界上下文、多个上下文映射关系，那么如何考虑自己的领域设计是否合理：
1、有些软件资产已经存在的，他们可以重用？
2、哪些资产是需要创建的，或者从别处获得？
3、这些资产是如何集成在一起的？
4、这需要什么样的集成？
5、假设已经有了现有资产和哪些需要被创建的资产，我们还需要做些什么？
6、核心域和那些支撑项目的成功几率如何？会不会出现由于其中一个失败而导致整个项目失败的可能？
7、在哪些地方我们使用了完全不同的术语。
8、限界上下文之间在哪些地方存在概念重叠？
9、这些重叠的概念在不同的限界上下文之间是如何映射和翻译的？
10、哪些限界上下文包含了核心域中的概念，其中使用了谢【evans】中的战术模式？
开发核心域的解决方案是一种关键性业务投入。
限界上下文是一个显示的边界，领域模型在这个边界之内。领域模型把通用语言表达成软件模型。创建边界的原因在于，每一个模型概念，包含它的属性和操作，在边界之内都具有特殊的含义。
限界上下文也不是旨在创建一个单一的项目资产，他并不是一个单独的组件、文档、或者框图，也不是一个jar或大流量, 但是这些可以用来部署限界上下文。
限界上下文可以包含模块、聚合、领域事件和领域服务等，限界山下文应该足够大，以能够表达所对应的整套通用语言。
限界上下文与技术组件保持一致。在使用IDE时，譬如eclipse或idea，一个限界上下文通常就是一个工程项目。在使用java时，我们可能从技术层面上讲一个限界上下文放在一个jar文件中，进行独立的版本演进，也可以借助OSGI或java8的jigsaw进行动态版本管理。
网友评论