Hi! You might be conflating the concept of Application with that of Service. The usual convention in enterprise architecture frameworks, is that if an App uses a set of IT Components, then these IT Component are required to enable the App. So, if App A depends on App B, then App A indirectly depends on all ITC used by App B because without those components, App B cannot be enabled and therefore cannot support App A at all. In other words, you cannot say that App A only depends on one ITC of App B because that is actually not possible.

In summary, if

• App A depends on App B, and 
• App A uses ITC C, and
• App B uses ITC C, D, then there is a derived (transitive) relationship between App A and ITC C, D because of the dependency between A and B. This is the expected behaviour. 

If you want to model that App B is able to provide a service to App A that does not depend on ITC D at all, then you need to model your application B differently.

One option is to split App B into two Apps B1 and B2, where B1 and B2 are children of B, and B1 depends on ITC C and B2 on ITC D. This would allow you to model the dependency between App A and B1 without any derived relationship to ITC D. However, this option adds unnecessary applications to the landscape.

An alternative is to use microservices. This option will not clutter the application landscape and keeps the original definition of App B. To model this, create two services provided by App B, B1 and B2, where B1 depends on ITC C and B2 on ITC D. Then create a dependency from App A to service B1 provided by App B. This might be the scenario you are actually trying to model. 

Finally, if there is direct dependency between App A and ITC C, then this must be modelled as well, regardless of the relationships between App A and other apps. 

Cheers!

Artur