public OutputEntity MyMethod(List listOfIds);

It appeared afterward that this method was very slow, and the client was already very upset about the low performance, which consequently caused big pressure on the teams by the superiors to enhance the performance.
After investigating the issue, it appeared that the list of ID’s sent as input consists of some ID’s that do not need to be processed, this criteria of “not need to be processed” is a business owned by team B, done by using properties of the entities these ID’s represent. So the  solution to this issue was one of the following:

1. Moving the business out of the API to the client application to do the filtering, since the calling method already has the entities themselves (not so good to move business out of scope!)
2. Let the API do the filtering, but this will worsen the performance because the API will have to retrieve these entities from the database in order to use its’ properties!

So is that a dead end? actually that was stupid! the situation was stressful enough and pressured by our superiors to enhance the performance that we missed a very simple fact: pass the list of entities themselves!

Stressful situations make us stupid, so make as less stress as possible on your team, help them to be smarter.

At the beginning I thought that this is something common when you use NHibernate with rich applications, so I didn’t pay much attention, but then it became a real headache.

One of the best colleagues notified me about an important note, which is that I was loading other domain objects from a shared  module (which I didn’t really need).
I checked the NHibernate config file, and removed the mapping line that includes those shared domain objects, and the time shrank to 15 seconds!

The moral of the story is that it’s ok to suspect code we inherit from others, other modules or projects, we might not gain anything by doing that, but I am almost sure that we won’t lose!