695
Views
4
Comments
Solved
Threshold Monolithic Service Module

What is the threshold for the architecture dashboard to say: "Too many public elements Monolithic Service Module ?".

What are the best practice amount of public elements ?


We have 18 public entities and 34 public server actions, the architecture dashboard indicates that this module has too many elements

2020-03-05 15-52-45
André Vieira
Staff
Solution

Hi Jacob!

What if I tell you that we don't have a threshold, i.e. that the pattern detection doesn't count the number of public elements? Would that change the way you look at this pattern?
If I told you that it was 20 what would you do? How would you separate those Services?

There's really no right or wrong answer to the question "What is the max number of public elements that I should have in a Service?". It might happen that you have a really big biz concept that requires a lot of public elements. But it also might happen that you are mixing too many biz concepts in the same Service, which could lead to problems in the future, and that's why we have this pattern.
The purpose of it and the way we frame the "How to fix" is not about keeping the number of the public elements below a certain threshold - hence we don't mention a threshold - it is about a deep and thoughtful analysis of the Service module identifying the biz concepts and understanding if they really should/need be grouped in the same Service. This leads to questions such as: Is the Service changed often by different teams? What business concepts do they "own" within that Service? Is the lifecycle of the Service (and dependent applications) impacted by having multiple business concepts in it? etc.

As with any other pattern we have in Architecture Dashboard, we provide the ability to flag those findings as false positives and we look into this data to determine patterns that are creating too many false positives and for which we might need a different approach in the pattern detection.

I know I'm not saying a number for the threshold but I hope you understand that that number is not really relevant and that by us exposing that in the pattern itself we would be much more limited in improving the pattern's detection.

So, coming back to your example, try to answer these questions:

  • Are all those 18 public entities strongly related to each other? Do they represent business concepts belonging to the same "family"?
  • How many teams do you have changing this Service? Are you having impacts on the lifecycle of the Service and applications because of that?

I hope this helps!

Cheers

2021-11-08 12-36-10
Pedro Canário

Hi,

Its because you have too many public elements probably contains too many concepts inside. Try refactor the module and split it into identified concepts.

The recommendation in the documentation is:

Module providing services with too many public elements.

Impact
A monolithic module with too many public elements probably contains too many concepts inside. The module becomes very heavy and hard to maintain, and the lack of granularity causes unwanted impacts for consumers that only require a subset of services.
How to fix
Identify the granular concepts inside the monolithic module and design a conceptual relation among those concepts, making sure that you get a graph with no cycles. Then refactor your monolithic module to split it into the identified concepts, respecting their conceptual relation.

You can see the documentation here: https://success.outsystems.com/Documentation/11/Managing_the_Applications_Lifecycle/Manage_technical_debt/Code_Patterns



Best Regards,

Pedro Canário

2024-07-05 14-16-55
Daniël Kuhlmann
 
MVP

Good information, but it does not answer the question, what the threshold is. It is not documented by OutSystems, I already asked if they can share that information.

UserImage.jpg
Jacob Dekker

Thank you! Looking forward to the reply of OutSystems 

2020-03-05 15-52-45
André Vieira
Staff
Solution

Hi Jacob!

What if I tell you that we don't have a threshold, i.e. that the pattern detection doesn't count the number of public elements? Would that change the way you look at this pattern?
If I told you that it was 20 what would you do? How would you separate those Services?

There's really no right or wrong answer to the question "What is the max number of public elements that I should have in a Service?". It might happen that you have a really big biz concept that requires a lot of public elements. But it also might happen that you are mixing too many biz concepts in the same Service, which could lead to problems in the future, and that's why we have this pattern.
The purpose of it and the way we frame the "How to fix" is not about keeping the number of the public elements below a certain threshold - hence we don't mention a threshold - it is about a deep and thoughtful analysis of the Service module identifying the biz concepts and understanding if they really should/need be grouped in the same Service. This leads to questions such as: Is the Service changed often by different teams? What business concepts do they "own" within that Service? Is the lifecycle of the Service (and dependent applications) impacted by having multiple business concepts in it? etc.

As with any other pattern we have in Architecture Dashboard, we provide the ability to flag those findings as false positives and we look into this data to determine patterns that are creating too many false positives and for which we might need a different approach in the pattern detection.

I know I'm not saying a number for the threshold but I hope you understand that that number is not really relevant and that by us exposing that in the pattern itself we would be much more limited in improving the pattern's detection.

So, coming back to your example, try to answer these questions:

  • Are all those 18 public entities strongly related to each other? Do they represent business concepts belonging to the same "family"?
  • How many teams do you have changing this Service? Are you having impacts on the lifecycle of the Service and applications because of that?

I hope this helps!

Cheers

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