I know I said in the previous article that it was the last article before we started learning about Database Design Fundamentals. But, I thought it may be wise to tell you about the apps we are going to build. But, as Murphy said, "Before you can do something, you first have to do something else." So, first I want us to look at how applications may interact with users and each other.
Application Interaction
Have a look at this image below:
You will see that we have 5 different applications:
Each of these 5 apps manages its own data, thus having its own database.
App 1 is both a Web Application and an API Service.
Apps 2, 4 & 5 are all API Services.
App 4 is a Messaging Service.
The user interacts with Apps 1, 2 & 3 via various user interfaces:
a Web Application in Google Chrome or Microsoft Edge
a Single Page Application in Google Chrome or Microsoft Edge
a Mobile Application
a Desktop Application
You will also see that Apps 1, 2 & 3 interact in return with other apps. The calling app is the Client and the app being called is the Service:
App 1 calls the API Service of App 2
App 2 calls the API Service of App 4 on a third-party server
App 2 also calls the Messaging Service of App 3
App 3 calls the API Service of App 5 on a third-party server
App 4 calls the API Service of App 5 on a third-party server
The important thing I want you to take away from this is that most modern enterprise applications may consist of various apps all working together to serve the organization's needs. Also, users can be either people or other apps.
The Applications We Are Going to Build
It is time for the Australian healthcare system to have a makeover, and we are going to build 5 applications to achieve that. Below, are the 5 areas that is going to need our help:
Healthcare
This application belongs to the Healthcare arm of the government and maintains a list of all people (read that as patients) who will need medical care. In addition, it will also host a formulary, which is a list of drugs (not the addictive stuff) the government will make available to treat such patients.
Practice
When a patient needs medical care, they will visit a doctor at a practice. The practice will retrieve the patient's details and medical history from the Healthcare system and will issue a prescription that will be dispensed by the pharmacy.
Pharmacy
The pharmacy will retrieve the patient's details and prescription from the Healthcare system and will dispense the medication.
Supplier
When the practice and pharmacy run low on stock, they reorder from the Supplier who in turn also has access to the formulary. This allows the supplier to know what to keep in stock. Once an order is ready for shipment it needs to be delivered with the help of a courier.
Courier
The courier is notified of a pending delivery and acts accordingly by picking up the parcel from the supplier and delivering it to either the practice or the pharmacy.
The Plan
The plan is to build each application with a different technology stack and database so you can see that there are many ways to skin a cat. Using the concepts of the first image in this article on application interaction, we will have many interactions between these applications such as ordering, notification, and patient and formulary updates to name a few.
As we progress, we will build different areas of the apps. This way, by the time we build the complete app, this should be familiar to you, reducing your learning time substantially.
Conclusion
I hope this gave you a little insight into where I am heading with this. Next, we will (for real this time) start with Database Design Fundamentals. See you there!