Currently our service is implemented using a multilayer architecture dividing the whole service into three:
However this introduces a lot of redundancy within our system. A common adage in the industry is "DRY" (Don't Repeat Yourself). The redundancy has increased the development time, and made the system more fragile and cluttered our code with "copy" methods.
To give a better idea, say we have a
Person service. This would require the following:
Personentity - JPA annotated class for ORM
- Repository service request - contains field values to be persisted of the Person domain object with additional persistence options
- Repository service response - contains field values of the Person entity
Person- class with business logic, domain fields and computed fields
- Domain service request - contains field values of
Personresource and additional business options
- Domain service response - contains field values of
Personbusiness object excluding those that shouldn't be visible to API users
Personresource - class representing what should be viewable to the API users
And things get worse when taking nested objects into consideration.
The current design facilitates difference between concerns (business, API, persistence), however:
- Currently, the differences are very small. This is causing us to have very similar classes with only minor differences
- Services returning service response objects with fields instead of just the objects itself hampers other services from depending on other services
- Is it worth it to go through with this design?
- What are our alternatives?
- What could we change to improve our situation?