14.8. optaweb Vehicle Routing 后端架构

后端代码组织在三个层中，如上图所示。

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

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

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

编译时依赖项只允许从外部层指向中心。遵循此规则有助于使域模型独立于底层框架和其他实施详情，并更精确建模业务实体的行为。随着正在推送到外文的演示和持久性，测试业务实体和用例的行为更为容易。

域没有依赖项。

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

插件以两种方式依赖于服务：首先，它们根据用户输入或来自优化引擎的事件调用服务。服务注入到插件中，该插件会将构建和依赖项解析的负担移到 IoC 容器。其次，插件实施服务输出边界接口来处理用例结果，例如对数据库保留更改或向 Web UI 发送响应。

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

service 软件包包含实施 用例 的类。使用案例描述了您要做的项，例如添加新位置、更改出口容量或查找地址协调。管理用例的新规则使用域对象表示。

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

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