Defining your data storage
My pet project has the following spec with 5 clear entities. The relationships between them are:
- An employer can post n jobs
- A jobseeker can save n jobs for later viewing
- A jobseeker can create n job applications
- A job application has one job
- A job application may have one resume attached
The features of the system are CRUding those entities under some rules and some kind of reporting.
When defining some relational data schema you usually sketch some boxes with your entities and the relationships between them. If you get any n to n relationship, you create another table and if you have inheritance you scratch your mind as you’ll have several options.
If your schema is complex, ORM comes handy to map from relational to objects. However there are some accusations against those framework about being slow or hard to understand. My main intent with this project is understanding stuff clearly, so I will discard using an ORM.
I will use some document database to store my data and I will split them in different services. As a first idea, the bounded contexts that I’m going to use are: User Service, Job Service and Job Application Service:
User Service
- CRUD employer
- CRUD jobseeker
Job Service
- CRUD job
- Save jobs for later viewing
- Get jobs by employee
- Get saved jobs
Job Application Service
- CRUD job application
- Reporting
Splitting services will allow me to practise some ideas behind microservices as circuit-breakers or consumer-driver contracts, but as well it’ll force me thinking more deeply about how to store my data. When you fetch a related entity with Hibernate feels really easy, maybe too easy if we’re worried about proper design and performance.
If you have to do a rest call through network to get an employer entity from job application service, you will think two times if storing an id in job application document is the best approach, or if maybe we should denormalize that data. You should have that line of thought with a relational database and a monolith middleware anyway, but microservices (or modular systems, if you want) encourages that for free.