Organizing packages after domain concerns leads us to an architectural structure, where the actual business, rather than technical details are reflected.

The business use cases handle all logic required to fulfill the business purpose, using all our module contents. They act as a starting point into the application's domain. The use cases are exposed and invoked via the system boundaries. The enterprise systems offers communication interfaces to the outside world, mostly via web services or web-based frontends, that invoke the business functionalities.

When starting a new project, it makes sense to start with the domain logic first, indifferent to system boundaries or any technical implementation details. This contains constructing all contents of the domain, designing types, dependencies and responsibilities, and prototyping these into code. As we will see in this chapter, the actual domain logic is implemented primarily in plain Java. The initial model can be self-sufficient and tested solely using code level tests. After a sufficiently matured domain model has been found, we target the remaining technical concerns that are outside of the domain module, such as accessing databases or external systems, as well as system endpoints.

In a Java EE application, a boundary is implemented using managed beans, that is, Enterprise JavaBeans (EJB) or Contexts and Dependency Injection for Java (CDI) managed beans. The topic EJB and CDI - differenciation and integration will show the differences and significance of these technologies.

Depending on the complexity of the individual use cases, we introduce delegates which are realized as CDI managed beans or EJBs, as well, depending on the requirements. These delegates reside in the control package. Entities are realized as POJOs, optionally annotated to integrate technical functionality such as specifying the database mapping or serialization.