I have a question: we are reviewing all our services. Earlier, we got recommendation from the consultant company which told us not to define Services more than 3 levels, it will create performance problem. I wonder if it is still the case today. Is there a limitation how many levels it can be when we define services?
For example: Service 1 |_ Service 2 |_ Service 3
this is the recommendation from the company.
Can we do like:
Service 1 |_ Service 2 |_ Service 3 |_ Service 4 |_ Service 5
What performance problems do they have in mind? The reference to parent service entity is just like a reference to a code entity, at least for services. Each service can have only one parent. Admitely the "in tree with root" could be heavy if you had endless levels but besides that I cannot see the problem. But this is not the point.
The idea of parent-child relation in services is that the "parent" service have a child that can also offered as sevice.
Service 1 |_service 2 |_service 3 |_service 4
means that there are 4 services offered Service 4, is a part of service 3 but can be also offered alone. Service 3 is part of service 2 but also can be offered alone. Service 2 is part of service 1 and also can be offered alone.
It's pretty confusing though don't think that leads to dramatic perfomance problems.
The question you should ask yourself is that: "Do we want 4 levels of services?"
The parent relation should not used for grouping similar services. The parent-child means "The parent is a service, it contains the child as service and the child could be offered standalone as service". If this is your need I don't think that 4 levels should make such a big difference. Admitedly the "tree" view would be heavy but not in a such dramatic way.
We do have 4 levels of services and so far we haven't see big problems. Admidetly the service list isn't quite big.