Specific to the Problem
An employee knows his laptop, but a laptop does not know an employee. The employee uses the laptop, and it's a good idea to put employee-laptop logic in the same package with employees.
Extension 1: To Separate or not to Separate, that is a Problem.
The 100+ interrelated DBs sounds dubious. In real world, most entities exhibit a community structure. It's likely that if you draw a graph of your DB you will find some natural clusters. It is based on this idea that we group functions into classes, classes into packages, and packages into applications.
It is undeniable that there are cases where a large number of states are interconnected densely by nature, where people don't try to separate them into classes, but bind them together in a context
For example, in a WEB frontend app, some information is ubiquitous, such as a summary of the current user status; in an electronic game, more than a few systems are interested in the player's actions. In all of these cases, you'd best put the states in a managed context, otherwise you have to pass them around verbosely.
Extension 2: An Unambiguous Design Principle for Overlapping Domains?
It's definitely normal to have overlapping domain concepts, because otherwise they won't live in the same project at all. Will you worry about how to launch a rocket when you work on a pet health monitor?
It's not always easy to identify the community for a class to live in. In fact, this is a popular research problem named community discovery. There are several heuristics, but none is dominating. Designing an architecture is still a nonautomated area and sometimes no one can tell you why exactly they think it's the best solution. It's not until recently that I learned to live with uncertainty about whether I'm making the "best" choice.
In this blog, the author mentioned a key difference between junior and senior developers:
It doesn't take much skill to notice a problem.
In fact, as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it. That's the way it's always been done, and they've learned to live with them, so they've stopped questioning it any more.
Junior developers however, get to look at everything again with a fresh pair of eyes: they haven't learned to ignore all the quirks yet, so it feels uncomfortable to them, and they tend to question it (if they're made to feel safe enough to voice their concerns).
Extension 3: What About a Good Design? Is it Unimportant?
Of course not. However, you won't learn real experience from reasoning or discussion alone. You only learn through practice.
My advice is to focus on the business scenario you are working on. You can build a package for employee salary management, and later another for employee equipment management. Now, you extract common logic from these two packages into a lower-level package Employee. You should put the business in front of your application, not the other way around. You package structure should mimic the domain structure, and lower-level functionalities grow out.
That being said, don't be afraid to make a bad decision. Many WEB apps are built with only three main packages, Controller, Service, and Model. They are functioning well anyway!