Discussion on software architecture

0

I am rewriting an application for better structuring it and I have some doubts.

The application is a football betting management system and has a web app for the manager and a mobile app for the bets to make. So, this application is currently used by three different customers and will certainly use them in the future.

I would like, unlike the current scenario, I did not need to repeat code for each of the applications. I would like to have a domain and identify which user is making use of the application based on the subdomain used. For example: user1.mydomain.com . Then I would know that the user accessing the system is user 1 and would use a token to access data from it in a common bank to all users differentiating the records by tokens.

Would it be risky to mix data?

I also thought about actually doing three separate systems and even got to draft the picture below. The API Bank is an API that will give me data about matches, teams, championships and so on. I imagined the Master Bank as being the bank that has all the data in common among all the different instances of the system, in case it would be all that will come from the API. And the other three banks being the banks of each of the instances. I opened this topic to listen to opinions and share experiences of how I can best implement this architecture.

What can I change?

Thanks to all who can contribute.

Obs : I want to use PHP + CodeIgniter to develop the web system and the mobile app will be written with Apache Cordova and the database used will be MySQL.

    
asked by anonymous 12.05.2017 / 15:50

1 answer

0

Legal its maturity in seeing conflicts of responsibilities between projects / softwares. I hope I can use your mistrust to recommend an architectural proposal.

  

Identification and separation of responsibilities

Identify the services of your solution . But try to see just the business of each one, and be blind to technological part - such as codes, domains, databases, etc.

  • Platform Administrator - create clients, manage access, plans, dashboards, etc;
  • Clients - each client will be a clientN.yourdomain.com .

Each of these two is an independent project. They do not share codes, classes, databases, anything. This is because they must have autonomy. Your administration should work even if there is no client, and your clients should function even if you take all your web-database administration and database.

  

How do applications - administration and customers - communicate?

In a first parsed, I would do it as follows:

  • Any platform upgrade that is done from administration to the client should be done via Message Queue .
  • All information the platform must collect from the client:
    • Some information, the client will inform their administration via Message Queue .
    • Other, real time , administration should consume a client API.
  • IMPORTANT : An application - whether admin or client - should never directly access the database of each other. This creates a super docking, and it sucks.

      

    Would it be risky to mix data?

    SIM . And you already knew that, but you asked for prudence, and that's healthy: +1 for you.

    Each client of yours must be a totally isolated instance. Each of your clients must have an instance of the web / api application, its own database instance, and its own storage area - do not go put client files in the famous upload folder % next to your application codes, huh?.

      

    Should I repeat code for each of the applications?

    Óbviou NO . All your clients should run the same source code, the latest update, and everything. And this code must be fully parameterizable. From setting up colors, titles, images, logos, as well as credentials, connectionstrings, storage locations, and finally toggles to enable features , features, etc. >

      

    One Server to rule them all?

    I saw in your drawing that you have a hosted server of everything - web application, api, databases, etc. This is not legal . The ideal is a server for accountability. One for hosting web applications - preferably one for your administration and another for clients - others for your database, and others for your storage file. This type of approche Cloud First , develop your solution so that it is already shaped to be hosted in the cloud.

        
    15.05.2017 / 09:53