16.8. OptaWeb Vehicle 路由后端架构
对于应用程序来说，域模型和使用案例是必不可少的。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 软件包包含实施用例的应用层。plugin 软件包包含基础架构层。
每个层中的代码进一步由函数组织。这意味着每个服务或插件都有自己的软件包。
16.8.2. 依赖项规则
编译时依赖项只能从外部层指向中心。遵循此规则有助于使领域模型独立于底层框架和其他实施细节，并更加精确地模拟业务实体的行为。通过演示和永久性推向外围，测试业务实体和使用案例的行为更加容易。
域没有依赖项。
服务仅依赖于域。如果服务需要发送结果（例如到数据库或客户端），它会使用输出边界接口。其实施由 上下文和依赖项注入 (CDI)容器注入。
插件以两种方式依赖服务。首先，根据用户输入或从优化引擎发出的路由更新等事件调用服务。服务注入插件，将其构造和依赖项解析到 IoC 容器的负担中。第二，插件实施服务输出边界接口来处理用例结果，例如对数据库进行永久性更改或向 Web UI 发送响应。
16.8.3. 域软件包
domain 软件包包含为此项目域建模 的业务对象，如 Location、Vehicle、Route。这些对象严格以业务为导向，并且不得受到任何工具和框架的影响，例如对象关系映射工具和 Web 服务框架。
16.8.4. service 软件包
service 软件包包含实施 用例 的类。用例描述了您要执行的操作，例如添加新的位置、更改载体容量或查找地址的协调。监管用例的业务规则使用域对象来表达。
服务通常需要与外层中的插件交互，如持久性、Web 和优化。为了满足层之间的依赖关系规则，服务和插件之间的交互以定义服务依赖项的接口表示。插件可通过提供实现服务边界接口的 bean 来满足服务的依赖项。CDI 容器创建了插件 bean 的实例，并在运行时将其注入服务。这是 control 原则的 inversion of example。
16.8.5. plugin 软件包
插件 软件包包含基础架构功能，如优化、持久性、路由和网络。
