OpenMRS Package Hierarchy

[edit]

Package Hierarchy

org.openmrs.* domain objects (e.g., Patient, User, Encounter, ...)
org.openmrs.api.* business layer api services (e.g., TransferPatientServices, HL7Services, DecisionSupportServices, ...)
org.openmrs.api.context.* classes/interfaces needed to create an OpenMRS context from which services are accessed
org.openmrs.api.db.* database api services aka CRUD (e.g., PatientServices, UserServices, EncounterServices, ...) — sub-packages for each implementation (e.g., hibernate)
org.openmrs.<module>.* application-specific classes (e.g., formentry)
org.openmrs.test.* unit test classes — sub-packages for api, web, formentry, etc.
org.openmrs.util.* utilities available to all OpenMRS classes
org.openmrs.web.* web-specific classes — sub-packages for generic web functionality and one for each webapp
[edit]

Comments

In this model, all API classes (including business and database layers) are placed within org.openmrs.api.*. Each new application (module) would get its own org.openmrs.<module> package for module-specific classes.

We have three main layers we need to accommodate:

  1. Database layer
  2. Business layer
  3. Application layer
Retrieved from "http://openmrs.org/wiki/OpenMRS_Package_Hierarchy"