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. 域软件包

软件包包含 为此项目的域建模业务对象,如 位置VehicleRoute。这些对象严格面向业务,不得受到任何工具和框架的影响,如对象关系映射工具和 Web 服务框架。

16.8.4. service 软件包

服务 软件包包含实施 用例 的类。用例描述了您要进行的操作,例如添加新位置、更改载体容量或查找地址的协调。监管用例的业务规则使用域对象来表达。

服务通常需要与外部层中的插件交互,如持久性、Web 和优化。为了满足不同层之间的依赖关系规则,服务和插件之间的交互按照定义服务依赖项的接口来表达。插件可以通过提供实现服务的边界接口的 bean 来满足服务依赖项。CDI 容器创建插件 bean 实例,并将其在运行时注入到服务。这是控制原则的 inversion 示例。

16.8.5. 插件软件包

插件 软件包包含基础架构功能,如优化、持久性、路由和网络。