16.8. OptaWeb Vehicle 路由后端架构

后端代码由三个层进行组织，在上图中显示。

org.optaweb.vehiclerouting
├── domain
├── plugin          # Infrastructure layer
│   ├── persistence
│   ├── planner
│   ├── routing
│   └── rest
└── service         # Application layer
    ├── demo
    ├── distance
    ├── error
    ├── location
    ├── region
    ├── reload
    ├── route
    └── vehicle

org.optaweb.vehiclerouting
├── domain
├── plugin          # Infrastructure layer
│   ├── persistence
│   ├── planner
│   ├── routing
│   └── rest
└── service         # Application layer
    ├── demo
    ├── distance
    ├── error
    ├── location
    ├── region
    ├── reload
    ├── route
    └── vehicle

service 软件包包含实施用例的应用层。plugin 软件包包含基础架构层。

每个层中的代码进一步由函数组织。这意味着每个服务或插件都有自己的软件包。

编译时依赖项只能从外部层指向中心。遵循此规则有助于使领域模型独立于底层框架和其他实施细节，并更加精确地模拟业务实体的行为。通过演示和永久性推向外围，测试业务实体和使用案例的行为更加容易。

域没有依赖项。

服务仅依赖于域。如果服务需要发送结果（例如到数据库或客户端），它会使用输出边界接口。其实施由 上下文和依赖项注入 (CDI)容器注入。

插件以两种方式依赖服务。首先，根据用户输入或从优化引擎发出的路由更新等事件调用服务。服务注入插件，将其构造和依赖项解析到 IoC 容器的负担中。第二，插件实施服务输出边界接口来处理用例结果，例如对数据库进行永久性更改或向 Web UI 发送响应。

domain 软件包包含为此项目域建模 的业务对象，如 Location、Vehicle、Route。这些对象严格以业务为导向，并且不得受到任何工具和框架的影响，例如对象关系映射工具和 Web 服务框架。

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

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

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