0

I have been the sole developer on a project for the past eight years. Right now it's one big monolith, but at this point it's really three separate apps, and those really need to be broken down as the apps use some of the same data.

My original plan was to break all the bits into microservices, but after researching the last month I've realized that event driven architecture would really benefit this app. It is also unfortunately tightly coupled with the data access since it's using entity framework.. So I guess my question is should I first implement the data repository pattern to separate the data access from the app, then break it into microservices, then implement the event driven? Or do I just do the whole thing in one step?

5
  • I have to say maybe I don't understand what this site is for. Mine, and a third of all questions asked seem to have downvotes. What exactly is wrong with my question? What kind of questions are we supposed to be asking? – Jhorra Jun 16 '20 at 21:11
  • It seems like every question get's a downvote lately. Don't sweat it. – JimmyJames Jun 16 '20 at 21:29
  • 3
    I'll look at this tomorrow but "do the whole thing in one step" sounds like a bad idea. – JimmyJames Jun 16 '20 at 21:31
  • 2
    Many questions get downvotes because many other people know the rules of the site, but rather than explain them to new users, they simple downvote instead of offering an explanation. The purpose of the site is to provide specific answers to specific questions. You have likely been downvoted because your question is too broad. Without significantly more background, your question is just too general to get anything other than a few opinions. The answers provided will also not serve anyone else who finds the question in the future. – Jason K. Jun 17 '20 at 15:48
  • I looked around, where are the guidelines or rules written to say this. – Jhorra Jun 17 '20 at 19:34
1

So before you redesign an application to use a different architecture, you should be really clear about what your goals are. Microservices are not a goal. Event Streaming is not a goal. These are approaches that can be used, given the right preconditions to achieve one or more goals. So before doing anything you need to identify what problem(s) you want or need to solve.

Based on your description, I'm guessing that the main issue is that you've got 3 identifiable systems that are maintained in the same code base. This tends to lead to issues as you try to make changes to one of them because of unintended impacts on the others.

If that's a fair assessment of the situation, the first thing is to ensure you have regression tests. Just to be clear, I am not talking about unit tests. These are valuable as well but they don't tell you if the applications are meeting their requirements. A lot of unit tests are really more functional in nature, and address regression needs.

Once you can quickly determine if the application is working, I would first focus on the shared pieces of the design i.e. any shared code and especially shared data.

Shared code typically needs to be broken out as a library. Shared data is much trickier. Ideally, you none of the data is created or updated by more than one of these applications. If more than one of your 'applications' in this monolith is maintaining this shared data, microservices are off the table for those 'applications' for now. However, if you have one 'application' creating and maintaining part of the data and other applications using it, I would recommend starting by breaking one such application out into it's own with it's own database (or at least it's own schema.) You can provide interfaces for the other applications to access the data or request changes to it. Often this is done with services but there are many options here. Once you've got the three applications in their own separate code-bases and isolated data, you will have a much easier situation to deal with.

As far as event-based architecture goes, I would shy away from going all-in on that. There's no reason you can't support both pull and push models in a single system. I would argue that events work best when aligned with supporting pull-based services. For example an event references an identifier that can be passed to a service for more detail. Events are great but the idea of building something that's purely event-based, beyond something fairly simple, strikes me as something that you might do if you just learned about events. There are lots of challenges with events as well as benefits. Not everything is a good fit for that approach.

2
  • I'll be honest, events terrify me, but the application gets a live feed from multiple hospitals. We get tens of thousands of updates from the hospital per day. The real reason I'm looking at events, is because as patients come into the hospitals the data can change so much and so fast from the hospital and doctors/nurses it becomes impossible to make efficient backups. With an event source I will have a way to track those changes, roll back, or roll forward if there are problems. – Jhorra Jun 17 '20 at 19:40
  • That does sound like a potential use case for events but I'm not sure events solve the problems you mention. It sounds like a situation where you want an insert-only DB design a.k.a a versioned DB table. The idea is that you never delete rows. You only add them. In a standard DB, you need an additional column to hold the version (or a timestamp) as part of your logical key. If you use a sequence for your version id, you should also track a timestamp. In the healthcare space, you will likely need a number of dates/timestamps on each record. This allows you to view data at a point in time. – JimmyJames Jun 17 '20 at 21:39

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.