Hi all! I’ve been going through Lagom’s documentation for Scala recently, as well as analyzing some examples here and there (like lagom/online-auction-scala and others) and I’m wondering… How unusual for you would it be to have more than one
PersistentEntity within one Lagom service - or in other words, within one
LagomApplication? @james notes here that it’s quite unusual to have more than one persistent entity/aggregate root per service, as it may suggest we’re building a service with more than one responsibility (thus - a service that won’t be autonomous), missing the key principles described in Sizing individual microservices.
The reason why I’m asking is because I’m trying to decompose my domain into Lagom’s concepts properly, and I find it not that simple. Possibly because most of the examples I’ve seen so far are rather simplistic, when it comes to the domain they’re modelling. In my case, I want to model something like a job offer. It has a few parameters that specify it and it ends up being a single
PersistentEntity, obviosuly. Now - we would like to have an applicant represented in our system/domain.
JobOfferEntity shouldn’t accept an application if applicant’s skills don’t match job offer requirements.
Assuming we stick to the rule saying that we should have only one
PersistentEntity in our service for handling job offers logic, we will end up having a list of all applicants (all users) within every single
JobOfferEntity (our aggregate root for a given job offer). For sure, that’s no good.
Accessing the read-side from the write-side (to get a list of skills for a given applicant for our job offer aggregate/entity) is even more of an anti-pattern, so I don’t even consider this. For a second I’ve been thinking about splitting applicant skills handling (
ApplicantEntity) and job offers (
JobOfferEntity) into separate services, but frankly… I think that might be a bit over the top, don’t you think? If one’s set of skills only matter in the context of handling job offers, there’s probably no reason to reach
ApplicantEntity via HTTP request (or some message broker) every time we want to issue
JobOfferEntity (or any other command/event that requires some applicant’s data). These two entities seem to be coupled strongly enough to keep them as close as possible.
Thanks for any comments!