So what makes a good application suitable for deployment on the SpringSource Application Platform? Since OSGi is at the heart of the SpringSource Application Platform, modular applications consisting of bundles with each representing distinct functionality and well-defined boundaries can take maximum advantage of its capability. The core ideas behind forming bundles require following good software engineering practices: separation of concerns, minimum coupling, and communication through clear interfaces. In this section, we look at a few approaches that you may use to create modular application for SpringSource Application Platform deployment. Please consider the following discussion as guidelines and not as rules.
Bundles can be formed along horizontal slices of layering and vertical slices of function. The objective is to enable independent development of each bundle and minimize the skills required to develop each bundle.
For example, an application could have following bundles: infrastructure, domain, repository, service, web as shown in the following figure.
Each bundle consists of types appropriate for that layer and exposes packages and services to be used by other layers. Let's examine each bundle in more details:
Table 4.1. Bundles across layer
| Bundles | Imported packages | Exposed packages | Utilized services | Exposed services |
|---|---|---|---|---|
| Infrastructure | Spring Platform bundles | Repository interface packages | None | None |
| Domain | Depends. For example, if JPA is used to annotate persistent types, then JPA packages. | Public domain types | None | None |
| Repository | Domain, Spring Platform bundles, ORM bundles, etc. | Repository interfaces | None | Repository beans |
| Service | Domain, Repository | Service interfaces | Repository beans | Service beans |
| Web | Domain, Service | None | Service beans | None |
Within each layer, you may create bundles for each subsystem representing a vertical slice of business functionality. For example, as shown in the following figure, the service layer is divided into two bundles each representing separate business functionalities.
You can similarly separate the repositories, domain classes, and web controllers based on the business role they play.