Not all accesses from every package of the Entity Control Boundary pattern are allowed or make sense, respectively. In general, the logic flow starts at the boundary, going down to the control and entity package. The boundary package therefore, has dependencies to both the control, if existent, and the entity package. Using boundaries of other modules are not allowed and won't make sense, since the boundary represents a business use case. Accessing another boundary would mean to invoke something that should be a separate, standalone use case. Therefore boundaries can only go down the hierarchy to controls.

However, dependencies and invocations from boundaries to controls of other modules are allowed and do make sense in some cases. Developers have to pay attention that the transaction scopes are still chosen correctly when accessing components from other modules. When accessing controls of other modules, it will also happen that they work with or return entities of that foreign module. This happens for more than trivial use cases and won't be an issue, as long as care is taken where the responsibilities are placed, and that the controls and entities are being used correctly.

Controls may access controls of other modules and their own and foreign entities. For the same reason as with boundaries, it makes no sense that a control invokes functionality of any boundary. This would be equivalent to starting new top-level business use cases within a running use case.

Entities are only allowed to depend on other entities. In some cases it will be necessary to have imports on controls, for example, if JPA entity listeners or JSON-B type converters exist that can implement sophisticated logic. These technically motivated cases are the exception where it should be allowed for simplicity to import these classes. Ideally, these entity supporting components, such as entity listeners or converters should reside directly in the entity package. Due to other dependencies and usage of delegates this premise cannot always be fulfilled, which should not lead to overly complex technical workarounds.

This also brings us to another more general topic.