(This is not meant to be a comprehensive "cookbook" or "list" answer of all possible design approaches. Simply an answer with one possible design approach.)
Frequently when dealing with a legacy system with a legacy database the database contains and maintains facts about a number of different concerns. Possibly they're closely related, or possibly not, but in any event you can actually separate these concerns and when you do you may also find that the way you interact with these concerns are different.
With respect to "the way you interact...are different" consider that even for the same set of information sometimes you're doing a transactional update on a single item, sometimes you're doing a specific query that will return 1 to 100 items without updating any, and sometimes you're generating a report that will return 1000000 items without updating any. Also sometimes you're interacting directly with only one of these concerns and sometimes you're interacting with two (or possibly more) at the same time. (See below list.)
In which case you can effectively set up a new microservice to be the owner of each concern, and each will talk to the legacy database of course in the proper way, but each will expose an API that is directly in the domain language of that concern.
By providing these "intermediate" microservices your system then decomposes more readily into "services handling particular needs" and you gain not just insulation from the legacy implementation but also modularity (with all that gives you) in your evolving system. And you might find that some constraints are loosened leading to a better operational environment all over - for example, you may discover a way to handle transactions fast without interference from your reporting needs, etc. etc. etc.
This is all very abstract - so here are some concrete examples:
Legacy database contains information about hotels. Room availability today, room availability in the future, historical room availability, and then maybe also room rates, upcoming promotions, financial information like taxes of various kinds that are paid for each room rate, geographical location, which chain the hotel is part of, etc. etc.
Legacy database contains information about inventory. What's currently in inventory, what's expected and when, what's currently in flight, damaged inventory, lost inventory items, inventory that needs manual handling, inventory age and when the inventory ages out and needs to be discarded, who owns the inventory, price of each item in the inventory (including, or not, historical prices), etc. etc.
- Example of dealing with multiple facets: Report on SKUs that are problematic in that they are frequently broken or lost in the warehouse and/or aren't supplied in a timely fashion, or cause other problems?
The legacy database contains information about customers. Contact information, what's currently in his cart, last time seen, order history, customer service history, financial information, etc. etc. etc.
- Example of an action dealing with multiple facets here: Should the customer be charged for his return of this item from this order, taking into account how often he orders from us and how much, and also taking into account does he seem to be "abusing" this privilege for a certain class of items?
And so on.