Rebuild Startup Company Codebase and Architecture with new technology

Question

I know that this is going to be a really broad topic but I have come to a point that I need guidence with my first steps on this matter.

I started working for a startup company related with financial services at the end of last year. It provides loans and micro credit services, it has plans to incorporate digital wallet services and also add multicountry operations.

After working with support and daily issues, I've been assigned to start rebuilding the complete backend architecture and codebase. The replacing technology has been chosen, we are going to remove legacy versions of PHP and Laravel code and start working with .NET Core 3.1 and C# language. The idea of course is to make it in a progressive way, replacing small units of funcionality mostly on the client apps that consumes the APIs.

The current backend environment consists of 3 repos:

• A custom back office system: PHP 7.1.33 + Laravel 5.1.46 (BE) | AngularJS (FE)
• Packages project (third parties integration and some business logic encapsulation): PHP 7.1.33
• Web API: PHP 7.1.33 + Laravel 5.2.45

I have always worked with already established architecture, so this is will be my first encounter with these kind of important decisions. I'm currently overwhelmed with the amount of information I've been reading about architecture patterns and design patterns. I don't even know where to start.

I have gathered some information about what kind of issues the current stack has, apart from deprecated versions. So this is important to have in mind.

What kind of procedure would you suggest? Should I create some proof of concepts projects? I'm having trouble to make decisions on which is going to be the most adequate combination of patterns , technologies or libraries.

My background as a developer has always been .NET variantions (+6 years exp) so there is no trouble with that. But for example, when it comes to choosing between Onion/Layered/Clean, Vertical Slices or Microservices architectures it is really difficult which suits better. The same happens with design patterns like Repository or CQRS.

I have little experience working with DDD (at least that I'm aware of using it consciously), perhaps this kind of business is a great opportunity to apply it. I decided to start reading Eric Evan's book but it's going to be a long road.

Let me know if more information is needed.

I would really appreciate your knowledge and experience.

Answer 1

In terms of the broad approach to tackling any new engagement as solution architect this material may help: https://morphological.wordpress.com/2021/01/27/your-first-project-where-to-start/ If nothing else it will give you some structure in terms of your approach and the big picture.

You need to focus on this mantra: "what problem do we need to solve". Firstly so that you focus on the problems and don't put the technology first. Also to think about what your problems are - prioritize them, and break big problems down into smaller more manageable ones.

Some slightly more specific advice

• Start capturing & defining the architecture - "architecture on a page" is a great place to start.
• Using that approach, do a set of diagrams (and develop your thinking) on each of these specific topics: Business Functions & Functionality (what "the business" need the solution to actually do); Logical Systems & Components; Data; Integration.
• Key aspects to consider include the users - who are they and where are they? How will they be using the system? The idea here is to start identifying if you're looking at a client-server architecture, or multi-client architecture where you need a robust UI / API layering; do you interface with lots of third parties? etc.
• Later on, once things start taking shape logically, start bringing in deployment and infrastructure.
• Take all of that and start looking at some cross-cutting concerns, specifically: Security; Observability (Logging, monitoring, alerting, reporting) so you can look after the solution operationally.
• If you don't know which pattern(s) to use then just keep things as simple as you can.
• Keep good design principles in mind, like high-cohesion and loose-coupling.
• Consider carefully which parts of the solution it's best to build yourself vs use something off the shelf. These decisions are likely to be guided by major technology decisions, i.e. if you decide to go Cloud, and you pick one of Azure / GCP / AWS then some of the next level decisions will be easier to make - because as you add constraints the number of options decreases.

General Advice about Patterns and Technology Selection

• Pick technologies that will do the job - and - which are easy to hire for. Finding good staff, now and in the future, is going to be a continual challenge, so try to use technology which is likely to enjoy relatively good developer/market support for the foreseeable future.
• Usually a solution will have a few key scenarios or drivers that tend to dominate. For example, if you were building an totally on-line service that is designed to be consumed through API's, then API's and integration is super critical to the success of your solution, so prioritize decisions around that.
• In a similar vein to the previous point, having done some initial analysis and architecture-on-a-page, identify if you have there are any specific system capabilities that are going to be big and critical. One that creeps into that camp can be async messaging - this might lead you to think about adopting some sort of industrial eventing system from the get-go.