Best architecture composition
Question

Hi community,

Our current architecture for a application can be seen in the current situation image. Scenario 1 is the architecture we discussed today.


The Google_IS module in the current situation is holding multiple Google API webservice integrations (for example: Google Sheets API and Drive API v3). We are thinking about splitting all Google webservices into different modules as you can see in the scenario 1 image. We are not sure if we have to hold on to the current situation or we should move to scenario 1. The application in the current situation is only using the Google Sheets API and therefore does not need the other API's. In Google_IS only the integration has been done (with some server actions to get the credentials and to get a specific spreadsheet) and in Google_CS this server actions can be called to get the actual spreadsheet that is needed) 

Hopefully someone can explain which scenario is better and why it is better (or maybe even another scenario is better?). If more information is needed to give a complete answer, I'll be happy to provide it

Thanks in advance,

Bart


mvp_badge
MVP
Solution

Drivers apply when to have several integration services with different systems, performing the same type of operation (e.g. printers) you can create several drivers exposing the same API, with specialized implementations (like the transparency services pattern). But indeed you should watch the video to get a better understanding of a Driver and other types of modules.

Regarding your second question, I cannot imagine a module called Google_CS. The Core services are Reusable Core Services with public entities, actions of a concept. Customer, Vacancy, Product are concepts, Google is not a concept, in my opinion.

If you have an action to get a spreadsheet by name or by id then you have a foundation service, on one of your Integration Services. If in your application, you want to see a spreadsheet of a given product, then your CS or BL would have the logic to know the specific id or name of the spreadsheet to pass as input to your action in one of your Google Integration Services.


mvp_badge
MVP

Hi Bart,


You can and should adjust the granularity of your Integration services according to their size and complexity. You can check this pattern in this course from minute 6:35.


Two notes I would like to give you though:

  • According to the naming convention, a driver module should have the suffix _Drv, so your module GoogleDrive_IS would become Google_Drv;
  • The application Google Integration should be a foundation and not have business logic, so seeing a CS module there is unexpected. I would definitely take out any business logic from a foundation application that can be reused by multiple applications, each one with their business logic.


Kind Regards,
João

Hi João,

Thanks for the explanation. I am going to check the video and I am also going to check the difference between a _IS module and a _Drv module since I am not sure what are differences at the moment (that's why I am calling them _IS for now).

I still have a follow up question on your second bullet point. Google integration should only contain the Google_IS module. Google_IS then contains the REST APIs and some server actions (GetSpreadSheet for example). Where should I move the Google_CS module to? Since there is some business logic in that module to get a specific spreadsheet that is needed for a application

Thanks,

Bart

Also when I check the video you mentioned they split the SAP_IS module into smaller _IS modules. What is the difference with my scenario? Not sure why they are splitting it in _IS modules and why you told me to use _drv modules. Maybe you could explain when to use _IS and when to use _Drv?


Thanks,

Bart

mvp_badge
MVP
Solution

Drivers apply when to have several integration services with different systems, performing the same type of operation (e.g. printers) you can create several drivers exposing the same API, with specialized implementations (like the transparency services pattern). But indeed you should watch the video to get a better understanding of a Driver and other types of modules.

Regarding your second question, I cannot imagine a module called Google_CS. The Core services are Reusable Core Services with public entities, actions of a concept. Customer, Vacancy, Product are concepts, Google is not a concept, in my opinion.

If you have an action to get a spreadsheet by name or by id then you have a foundation service, on one of your Integration Services. If in your application, you want to see a spreadsheet of a given product, then your CS or BL would have the logic to know the specific id or name of the spreadsheet to pass as input to your action in one of your Google Integration Services.


mvp_badge
MVP

I'm sorry, I thought I read GoogleDriver_IS not Google_IS and thought you wanted to have a Driver. Now that I understand you mean Google Drive, it should be indeed a GoogleDrive_IS.

Regarding the purpose of splitting, it is explained in the video. You want to avoid have a large module with everything that will have many people changing them it, and that every application is consuming, creating a bottleneck. In that case, it would be preferable to split it into smaller modules, where you can have one developer working on, let's say, Google Drive and the other on Google Sheet and other on Google Calendar modules.

This makes sense. Thanks for the information :)

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.