Best Practice regarding calling data of Application A for Application B?

As you say, there's no one "right" answer to this.  I've had some team leads in the past who insist that different applications on a platform should be so disconnected in terms of application precedents, that they could be moved to whole other environments and still work together the same.  I usually don't go to that extreme unless I have specific reason up-front to expect the applications might someday need to migrate to separate production environments. 

My preference is usually to form a "parent child" hierarchy, where one application is considered the "parent" and whose artifacts we assume can be freely used by "child" application(s), and thus the only queries / tools / etc we'd need to create for the child application(s) would be those which apply exclusively to that application.  [This is also in addition to a "global tools" applicaiton which can exist separately, be used by all, and not refer to any artifacts outside its scope.]  In general this method works pretty well, though it can get a little hairy in the face of a super strict deployment regimen (depending on how many developers there are and how active development is).

I believe there are 3 possible patterns here:

1. Make Application D and A the same Application. Now you have no reason not be to able to access the same data
2. Refactor Application A so that its Datastore and dependent datatypes sit outside in their own Application package, and (as Mike describes) make this new "Application" a child of Applications A and D. That is, the new (data only) Application functions like a shared "library" but instead of serving up functions/rules it provides data services
3. Expose Application A's data via WebAPIs. So Application D has to call those WebAPIs to CRUD the data that is shared with Application A

(there may be others that haven't occurred to me)

There are all sorts of pros and cons for each of the above (a pro of keeping the Applications separate is different Development teams can develop concurrently and trip each other up less than if it was the same application. At the same time, encapsulating your data objects means both parties have to be aligned when it comes to a deployment!). There are some common issues (how to ensure that data is "locked" so that only one update can be made at a time so as to not have transactions mysteriously disappear.

Thank you both for your input. Highly appreciated. I was not looking for an "right answer" here. More like your experience and how your solved it. I think on that senior/lead level we can still improve our exchange within the community. I think there are really valuable lessons to share. 

To my mind there's one key question that needs to be addressed before we can assess what anyone should do, more like 2.

How stable is the data in Application A?  How much work is being done on Application A?  Is it still having features added, or still having bugs fixed routinely?  If it is, using A's objects poses a problem, as another team will have ownership and could edit things your application depends on without warning you about it.

What you can do:

Use A objects such as A query entities and accept risk, especially if you inform A's team that you'll be using them or if work on A is minimal.

Meet with A, establish ownership of objects and require that proposed changes have to be approved by owner or both teams before they're allowed to go forward.

Offload objects you both need onto a Common or Universal or Utilities application, give it an owner, make all teams go through approval to change things, and hope that objects there are almost never modified.

Copy paste is your friend:  Duplicate from existing all the A objects you want, then attach your own application prefix to them and use them all you want.  Then you can even tweak the queries if you want to.  Both teams are insulated from each other's changes until someone on A changes the data model itself without warning anyone. (However, in this model you also won't get the fixes to horrible catastrophic bugs with the same objects that they fixed without telling anyone about them, either)

Two data stores which use the same DB scheme can be considered as a good option, so objects wise, it will not take any object dependencies from other applications during deployments and Application D's code can remain on its own by using its own application code. However, any DB changes we make should get approved to understand the effect on the change on both the applications.