Let's have a closer look at the boundary package. The idea was that all business use cases called from the frontend or outside of the system are initiated here. Invocations for creation, update, or deletion of users, first land in classes residing in this package. Depending on the complexity of the use cases, the boundary either completely handles the logic itself or delegates into the control before becoming too complex.
For a Java enterprise application, classes in the boundary package are implemented as managed beans. As mentioned before, typically EJBs are used here.
If the logic in the boundary becomes too complex and not manageable within a single class anymore, we refactor the logic into delegates that are used in the boundary. These delegates or controls are placed in the control package. They typically fulfill more detailed business logic or handle database or external system access by acting within the technical transaction that was initiated in the boundary.
This structure increases cohesion and reusability and honors the single responsibility principle. The structure of the business use case becomes more readable, once we introduce these abstraction layers. You can start by looking at the boundary as the entry point of the use case, and retrace every delegated step one after another.
In Domain-Driven Design language, the contents of the control package includes services, transaction scripts, factories and repositories. However, the existence of a control package for business use cases is optional.
At the heart of our domain we have all entities and value objects. These, together with transfer objects, build up the model of our domain module, the objects that a use case typically deals with. They are organized within the entity package, the last one of the Entity Control Boundary pattern.
Now, what about presentation-related components and cross-cutting concerns such as Interceptors or framework plumbing logic? Fortunately, in a modern Java EE project required framework plumbing is kept within limits as we will see in Chapter 3, Implementing Modern Java Enterprise Applications. The few things that are required, for example bootstrapping JAX-RS with the application activator class, are placed in the root package of our project or in a specific platform package. The same is true for cross-cutting concerns such as technically motivated interceptors that are not bound to a specific module, but the application as a whole. The number of these classes is typically not too high; if so, then a dedicated package makes sense. The danger of having such a platform package is that it naturally tempts developers to put other components in there as well. This place is just meant for the few platform specific classes; everything else should reside in its own business motivated module package.
The following is an example of the users module, using the Entity Control Boundary pattern:
