0

I work in a software company with a single product, a 25 year old monolith application (1.2m lines of code) handling all HR related data (employments, salary, collective agreements etc.).

I've been put on a team that needs to research how we can modernize our application and so I've started reading up on different design patterns and architectural styles. The entire developer department, including me, have had this idea that a cloud native, microservices architecture is a no brainer, but the more I read about the style the more I seem to doubt that this style is actually compatible with our extremely complex and large business domain.

A couple of examples for better clarification:

An employment is terminated

  • All work times and absence items after the termination date must be deleted.
  • According to the employees collective agreement, a last date of salary must be set.
  • The employees vacation, flex, time off in lieu account etc. must be paid out or used before this date
  • The employees logins our platforms must be revoked
  • Our integration partners must get the information that this employee is no longer with the company
  • etc...

A shift is created

  • If the shift is on top of a vacation period, the vacation account must be deducted.

  • if the shift exceeds the collective agreements max work hours for the given period(month, week etc.). The shift should not be created OR there should a created an overtime addition for said shift

  • +a million other events triggered in the dependencies

These examples does not even start to cover the complexities of what happens when a collective agreement changes and the impact that can have on salary, accounts etc.

It seems to me that our business boundaries are too large to cover by small microservices without having an absolutely wild amount of redundancy, in addition we are handling peoples salaries. Every part of the CAP principles (consistency, availability, partition tolerance) are all of high importance.

What are your immediate thoughts on the matter?

1 Answer 1

2

Nothing here seems fundamentally incompatible with microservices. Sure, you've got lots of business logic but the architecture doesn't affect that.

All work times and absence items after the termination date must be deleted.

Send a message to the "work schedule service" and the "absence service" to delete those items. Those microservices process the message.

According to the employees collective agreement, a last date of salary must be set.

Send a message to "collective agreement rules engine" to get the last date, process the response and send a message to the "salary service" to set the last date.

The employees vacation, flex, time off in lieu account etc. must be paid out or used before this date

(Seems this is more something the employee must work out, not an architectural concern)

The employees logins our platforms must be revoked

Send a message to the "user service" removing the logins.

Our integration partners must get the information that this employee is no longer with the company

Send a message to the "parter integration service" (or services) which can do whatever they need to do.

If the shift is on top of a vacation period, the vacation account must be deducted.

Send a message to the "absence service" which can handle it appropriately.

if the shift exceeds the collective agreements max work hours for the given period(month, week etc.). The shift should not be created OR there should a created an overtime addition for said shift

Send a message to the "collective agreement rules engine", then either reject the shift or message the "salary service" with the overtime information.

It seems to me that our business boundaries are too large

Feels to me more like you haven't fully decomposed the boundaries in your system, but only you can really answer that.

2
  • Thank you for the insight! - It seems that the correct way to handle data in microservices are by having a separate DB for each service - but many of our objects. e.g. a Worktime naturally has a foreign key to the employee object, how do you handle cross boundary relations like that in these situations
    – Matt Baech
    Jun 15 at 10:45
  • 2
    Foreign keys across boundaries should be natural keys, not synthetic ones. Your employee certainly has an ID which is used in all employee-related contexts. The only thing you lose is database enforced foreign key constraints (which is unavoidable if you decouple the data into separate services). If you have references among things that have no obvious natural keys, that may be an indication that they should probably go in the same microservice. Jun 15 at 11:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.