Are microservices unfit for our domain logic

Question

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?

Answer 1

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.

Answer 2

You've described multiple business requirements which can be modeled in many architecutre styles.

Ask yourself few questions:

• Does the system need to scale?
• Does the system features need to have independent deployments?
• Do you want to split the work between multiple teams?

If you got at least one yes answer, then yeah, you can go with microservices. But keep in mind that microservices will add even more complexity to your system, distributed systems are difficult to work with.

I am not sure if you want to rewrite or to refactor your system. In case of rewrite you would need to slow down development of new features in the old system, so that you will not be forced to chase your own tail. In case of refactoring you would need to clean up your monolith internal boundries first.

Both scenarios are difficult, but not impossible to pull off. At least that's what I've read on the subject.