Data Hospital
Sick way to treat your byte hazardous patients.
The Problem
Billie is integrated with numerous of external services that provide us e.g. customer bank data, risk reports, etc. There is entirely no guarantee that a service has 24/7 uptime or the data they provide is unquestionably correct and complete. Eventually, “fide sed cui vide” kicks in. We need an ecosystem to ensure the validity of incoming (relatively untrusted) bytes.
The Solution
Data
Data is raw, unorganized facts that need to be processed. Data can be something simple and seemingly random and useless until it is organized.Information
When data is processed, organized, structured or presented in a given context so as to make it useful, it is called information.Source: http://www.diffen.com/difference/Data_vs_Information
Hospital tries to transform data into information, if possible. If not, then the service will fulfill a diagnoses board, meaning the processing of data is no longer possible. But one step at a time.
Strategy inception
What regular hospital looks like? Patients, doctors, diagnoses… To diagnose, a doctor must have some knowledge base. Firstly one needs to understand what’s wrong (if any) with the patient and then apply different methodologies to cure a sick man.
When data comes, it eventually gets wrapped (becomes a patient) and then goes to a hospital. Patient already might have some diagnoses. Therefore he comes to the medical institution with his board (ideally it’s empty).
The patient goes to every doctor, and the latter one decides can he work with that visitor or not. If yes, then prescriptions are invoked. Data specialist iterates over and checks if one fits the patient’s state. In case of a match: prescription strategies to be run. Or not. Here’s flow:
When executing the prescriptions (including or not the strategies) we add diagnoses to the board. Diagnosis can be different: good or bad.
Hospital in every case must deliver at least one diagnosis. Ideally, it has to state that the patient is healthy and no any actions need to be taken.
Did you notice the healed severity? Indeed, doctors here are not just to write down the positive or negative conclusions regarding patient’s health. They also are supposed to cure our poor fellow.
Imagine we got data related to customer’s bank account. And all of a sudden there’s no IBAN! Sad. But hey, there’s account number, and we know bank’s code. So here comes the prescription: use those two values and create German IBAN, update patient’s state.
Another upcoming strategy will check if IBAN is empty. If it’s empty, then a diagnosis will be unpleasing and later on proceeded by other services, e.g. create an HTTP exception and deliver it to frontend or Slack or Sentry or wherever.
Usage in Symfony3
Doctors, Prescriptions, and their Strategies are defined as services. The entire configuration is set in YAML file, thanks to tagging and compiler passes. I’ve mentioned the IBAN prescription strategy. Now let’s see how will it look like in action.
Once the services are defined and tagged, right about time to compile them (don’t forget to include the configuration file).
That’s it. Now, let’s introduce new hospital to patients.
Summary
Now you are ensured that after the health check, the part of your system — that relies on information you get from your provider — won’t be turned into exceptions dust.
The system, in the end, is highly decoupled and rich of SRP. You can combine strategies with different prescriptions and even doctors. With time, men in white become brainy, making your system much more responsive and smart.
Thank you for attention, have fun! :)
