The important aspect while designing a Java EE app is to make it human understandable. Apart from code, the design should also be human friendly, so that any software designer can look at the design and easily understand the whole idea of the application.
The idea of this tutorial is to design and layer a Java EE application not horizontally by technologies instead structuring the application into cohesive units vertically.
Design a Java EE app for a Doctor clinic. Which will serve the following business needs.
- Compounder adds a new patient and creates a prescription card for him.
- Doctor provides medicine/tests required on prescription to the patient.
- Compounder /Doctor can search an existing patient to check prescription history.
- Compounder take payment from patient.
We have taken many interviews on designing and most of the time people jump on to the technologies and three-tier architecture. However, the focus should be on dividing the application on to modules, driven by the business needs and not by technologies and then use MVC / ECB patterns to layer the application code horizontally. How’s and why’s should be considered later once we have the module design ready. Therefore, the approach should be as follows:-
- Divide the application into modules based on business needs.
- Use modern design patterns like MVC to structure the code.
Now if I divide the above problem into modules. I will come up with below object diagram based on business requirement. The modules which I can think from problem statements are prescriptions, payments, doctors, compounders and patients.
Fig 1, Application Design
As you can see from the details all the business needs are fulfilled. Now we can follow MVC design pattern to structure our code.
Requirement 1 # Compounder adds a new patient and creates a prescription card for him.
The above requirement is full filled by API 1 exposed by module Patient and Prescription as both of them have a create API which compounder can use.
Requirement 2 # Doctor provides medicine/tests required on prescription to the patient.
Doctor can use API 3 from Prescription to add tests and medicine on prescription
Requirement 3 # Compounder/Doctor can search an existing patient to check prescription history.
Doctor/Compounder can use API 2 from Prescription to search prescription based on patient id. Patient ID can be retrieved from API 2 exposed by Patient.
Requirement 4 # Compounder take payment from patient.
Compounder can use API 1 from Payment to generate bill and associate the payment with prescription id. Prescription ID is already available from API 1 while issuing prescription card to the patient.
With the above exercise we have achieved good design that vertically layered the business problem into modules based on business requirements and can easily be understandable by any software designer/ engineer.