Currently my architecture is a monolithic block that handles a really specific duty. Now it needs to be generalized.
Right now it handles a request and all processes (1 or many) associated to it. There’s a class Request and a class Process and since it serves one specific duty this model was OK.
Right now I need to split both classes to achieve modularity. For instance, the Request class should be split. So I’ll still have a Request class, which holds general request information, and many RequestDetailsForServiceOne, RequestDetailsForServiceTwo and so on, that hold detailed information relatively to a specific type of request. Equally for Process.
The question right now is: how to bind together Request class with RequestDetailsForServiceOne (at run time)?
I had thought about Dependency Injection, but RequestDetailsForServiceOne and RequestDetailsForServiceTwo doesn’t share any common behaviour, (that classes only store some properties), this way will drive me to code an IRequestDetailsForService completely empty. That sounds as a code-smell to me.
Would be a better idea in this case use, (inside Request/Process class) a Dictionary of properties and completely avoid RequestDetailsForService* classes?
I don’t really like the loss of type-checking that this way get me back. What would be an ideal solution?
6
You basically have two approaches that can compliment each other, but they have different mechanisms.
Step 1: Define what success looks like
Before you begin, you have to define the target architecture. Are you just creating modules in a monolithic application, or are you actually breaking that apart into microservices?
- Define what modules/services you need
- Define any qualitative requirements you have (i.e. must process X requests/second)
- Clarify authorization responsibilities
There’s obviously more things to consider, but these will get you thinking in the right direction.
Strategy: Strangler Method
The Strangler method basically has you build the new thing you are migrating to, and then have your legacy code start using that instead of the legacy code.
Strategy: Mikado Method
Named for the book I learned it from, is an approach to discovering what the steps are to get from anarchy to order. It embraces version control as an enabler, and has you rolling back or abandoning branches when you get stuck.
The general approach works like this:
- Decide on the refactoring you want.
- Attempt the refactoring on a new branch
- If successful, merge your changes
- If the changes become too pervasive or difficult, identify the blocker and add that as a pre-requisite step
- Abandon the failed branch (delete it)
- Start over with the new step first.
You very well may need to do this when factoring out the legacy code that is replaced by the new thing you created in the Strangler Method.
You can make it modular with an “encapsulation” approach instead of “inheritance”.
Only the process needs the specifics, so it should be de-serializing the specifics there.
So you should have a Request as usual, but then a ProcessSpecificData string (or byte[]) field.
This completely decouples your processes from the Request Handler module.
It MAY be even better to have the processes deserialise “all” of the data. That would further decouple the processes. The Request Handler would deserialize enough to route to the correct process, but then it would simply pass that process a single string (or byte[] array).
With this level, it will be possible for a Process to run directly on its own, which would be nice for testing.