semmanuel
/
MyNotes
forked from jvilarroig/MyNotes
1
0
Fork 0
Code Pull Requests Activity

Update WhyDecoupling.md 

Signed-off-by: Javier Vilarroig Christensen <javier.vilarroig@msf.org>
This commit is contained in:
Javier Vilarroig Christensen 2025-02-13 15:49:50 +01:00
parent 84ac409dd4
commit b1fb5b8e22
1 changed files with 32 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
WhyDecoupling.md
View File

@ -5,7 +5,26 @@ Technical debt is risk.
* To reduce complexity.
Risk is proportional to complexity.
* To reduce risks linked to a future platform evolution.
# Subsystems in the wrong place
## Baby Steps approach
We can change the system in slow baby steps, looking for low risk.
* Create the table for the data needed in the solution datamodel.
* Create the sync API in the taget solution datamodel.
* Create the code to use the API to populate the table.
* As a task that can be used in the scheduler.
* Incremental resync.
* Full resync.
* Test different scheduler configurations for this resyncs.
* Ensure that the table contains all the information __needed__ and __only__ the information needed.
* Ensure that the table is timely updated fullfiling business needs.
* Identify attributes that depend on external data
* Make them use the data in the new table.
* If they are not in the table, the can be included in the table and in the API.
### About the table contents
Data in the table does not require to be exactly the same as in the origin solution.
Data can be digested and transformed to fit the solution needs.
This will help to reduce the complexity in the datamodel and manage it in the Java code in the sync service.
## Subsystems in the wrong place
We have some subsystems, like _Feedback_ or _Notifications_, that were initially designed for the Articles dataset.
We tried to make them as generic as possible.
When we started to build separate dataspaces/datasets for other solutions,
@ -18,3 +37,15 @@ This will allow us to:
* Give space for specialization.
* Remove inter dataspace depedencies.
* Advance work for the moment we move to a differen apps per solution.
# More points
* What we want to do is refactoring, no changes in functionality.
* We have different solutions that cover needs from different groiu
* Currently solutions depend on internals in the other solutions
* We went for the cheap solution, without really analysing the risk
* We can define the new data schemas and the transmission
# Patricks Challenge
* Functionality can be already part of the new product and we will have wasted time
* Example: Feedback