[FOLIO-3954] Merge mod-notify, mod-sender, mod-email and/or mod-batch-print Created: 16/Jan/24  Updated: 06/Feb/24

Status: Draft
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Tech Debt Priority: TBD
Reporter: Julian Ladisch Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: architectural
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Sprint:
Development Team: Volaris
RCA Group: TBD

 Description   

At least some of mod-notify, mod-sender, mod-email and mod-batch-print should be merged into a single module while keeping the existing API endpoints. There is no need for such tiny modules. Each additional module takes significant additional resources when deployed, and requires significant paperwork for releases. The modules are too granular.

No reason for this granularity has been shown:

  • Service Functionality: The four modules serve a single purpose and are highly cohesive.
  • Scalability: No bottleck is expected in these modules.
  • Fault tolernance: The functionality doesn't have a need for high fault tolerance that separate modules may provide.
  • Code Volatility: The code is changed infrequently.

Lines of code as reported by Sonar (click link to open Sonar report):

Module Total lines of code Java lines of code XML lines of code
mod-notify 1,362 968 394
mod-sender 707 344 363
mod-email 1,800 1,406 394
mod-batch-print 1,077 655 422

mod-batch-print design document: https://folio-org.atlassian.net/wiki/display/FOLIJET/mod-batch-print

 



 Comments   
Comment by Charlotte Whitt [ 05/Feb/24 ]

Julian Ladisch Jakub Skoczen Jenn Colt Kirstin Kemner-Heek - I’m not sure why this ticket has been created, and why it’s linked to https://folio-org.atlassian.net/browse/TCR-33.

Maybe the Volaris team one day will be able to pick up the work merging those four small modules, but for the mod-batch-print module to be approved, it’s completely out of scope to do this work.

This work https://folio-org.atlassian.net/browse/FOLIO-3954 might be something the FOLIO project will do when the app and platform consolidation work is being implemented - BUT not now for Quesnelia!

Comment by Julian Ladisch [ 05/Feb/24 ]

Hi Charlotte,

this ticket has been created because the modules are too granular, this is technical debt. The new module mod-batch-print increases the technical debt and therefore TCR-33 is linked to this issue.

This issue is in state “draft” and doesn’t have a target flower release, therefore it’s NOT scheduled for Quesnelia. Why do you assume it might be scheduled for Quesnelia?

From the Module Technical Evaluations:

Evaluation of whether the module is a good architectural fit is out of scope.

Therefore this ticket is NOT linked to TCR-33 with “is blocked by”, but only with “relates to”. That way architectual issues found during evaluation are moved out of the way and don’t interfere with the acceptance process. The link redirects people so that the discussions about architectual issues take place in this ticket and not in the module evaluation process. This ticket is kept so that the raised architectural issues are not lost but can be worked on at a later time.

Why do you assume the architectual issues might be in scope of the module evaluation?

Generated at Thu Feb 08 23:32:00 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.