16.8. OptaWeb Vehicle Routing 后端架构
域模型和使用案例对应用程序至关重要。OptaWeb Vehicle Routing 域模型位于架构中心,并由嵌入用例的应用程序层周围。路由优化、距离计算、持久性和网络通信等功能被视为实施细节,并放置在架构的最顶层。
图 16.2. 应用程序层图
16.8.1. 代码机构
后端代码分为三个层,如上图中所示。
org.optaweb.vehiclerouting
├── domain
├── plugin # Infrastructure layer
│ ├── persistence
│ ├── planner
│ ├── routing
│ └── rest
└── service # Application layer
├── demo
├── distance
├── error
├── location
├── region
├── reload
├── route
└── vehicle
service 软件包包含实施用例的应用层。插件 软件包包含基础架构层。
每个层中的代码按功能进一步组织。这意味着每个服务或插件都有自己的软件包。
16.8.2. 依赖项规则
编译时间依赖项仅允许从外部层到中心。遵循此规则有助于保持独立于底层框架的域模型和其他实施细节,以及更精确地对业务实体的行为建模。随着演示和持久性被推送到外围,可以更轻松地测试业务实体和使用案例的行为。
域没有依赖项。
服务仅依赖于域。如果服务需要发送结果(例如,到数据库或客户端),它将使用输出边界接口。其实施由 上下文和依赖项注入 (CDI)容器注入。
插件通过两种方式依赖服务。首先,它们根据用户输入或路由更新等事件调用服务,来自优化引擎。服务注入插件,将构建和依赖项解析的负担移到 IoC 容器中。其次,插件实施服务输出边界接口来处理用例结果,例如保留对数据库的更改或向 Web UI 发送响应。
16.8.3. 域软件包
域 软件包包含 为此项目的域建模业务对象,如 位置、Vehicle、Route。这些对象严格面向业务,不得受到任何工具和框架的影响,如对象关系映射工具和 Web 服务框架。
16.8.4. service 软件包
服务 软件包包含实施 用例 的类。用例描述了您要进行的操作,例如添加新位置、更改载体容量或查找地址的协调。监管用例的业务规则使用域对象来表达。
服务通常需要与外部层中的插件交互,如持久性、Web 和优化。为了满足不同层之间的依赖关系规则,服务和插件之间的交互按照定义服务依赖项的接口来表达。插件可以通过提供实现服务的边界接口的 bean 来满足服务依赖项。CDI 容器创建插件 bean 实例,并将其在运行时注入到服务。这是控制原则的 inversion 示例。
16.8.5. 插件软件包
插件 软件包包含基础架构功能,如优化、持久性、路由和网络。