The answer to your question: Can a Drupal Commerce catalog show different domain-aware products? is "yes." Mostly because Drupal Commerce simply uses content and Views to build catalogs, so if you can get Drupal to do something, Drupal Commerce is most likely along for the ride.
But I want to dig a little deeper to help you understand the problems you will uncover as you try to build something like this. Drupal Commerce 7 works on 2 levels (the version for Drupal 8 is much different):
1) Node level - Content with a title, a url, and published settings are best kept as nodes in Drupal 7. That suits Drupal Commerce well, since if you want to display a product, you must do it with a product reference field on a node. Most of the content related to specific products (a specific size/color/configuration) are actually injected fields. Injected fields get replaced automatically using ajax when an attribute field (size/color/configuration) is changed. This presents the biggest challenge for domain/translation.
2) Entity level - Lots of things in Commerce are simply implemented as custom entities. This includes products (not product displays), Orders, Line Items, etc. Products are the most likely to give you problems. For example, if you set a product display (node) to be certain domains, and products to be other domains, what do you expect to happen?
The Domain Access module is built to work with nodes exclusively. While some effort has been put into making a generic entity solution, it has many failings, most of which include a buggy and bloated data-entry interface. If I were to build such a thing, it would require a few patches to make it useable and understandable to the "store administrator."
For translation, you have a similar problem. You will need to decide whether you want to be able to translate certain fields (titles, description) or entire nodes/entities (a complete copy of the about us page, including attachments).
Most likely, you will want field-level translation. In that case, product pages that use product-level content (pictures or description that are a part of the attributes, like color/size/configuration) have a difficult problem to solve. The node would need to bring in a translated version of fields, and (optionally) bubble up product-level (read: entity-level, not node level) translated versions. If this sounds confusing, it's because it really is. We have multiple sources of content, all that would require some form of field-level translation.
The good news is, you can confirm this works in a matter of minutes with commerce_kickstart version 1 plus your domain and translation modules of choice. Note that field-level translation is supported by search_api, which means that your catalogs that should respond to domain and language, is possible and works without patches (this was not always the case).
The bad news is, while this is relatively easy to build as a demo, in practice, the resulting mess of products, translations, and page-level content becomes very hard to represent in a administrative interface in such a way that your average non-drupaler would know what's going on. For example, lets say you have a tshirt shop that sells shirts in two colors and two sizes. How do you describe to your store administrator that the color "red" is a taxonomy term that needs to be translated because it's connected to products which are connected to the page they are on? It's 3+ levels deep. Quite an abstract problem.
Your question isn't really suited for a "how to" because there many variations on your request that would completely change how I would set up the underlying information architecture. Something else you might consider adding to your architectural plan would be a comprehensive way to deal with multiple currencies in the face of domain/translation combinations.
// Edit: Here are some module recommendations:
- I wouldn't use Domain Access if you are trying to control product visibility with domains. It's too messy. It's much easier to simply create a taxonomy term and then build a custom views condition that compares the taxonomy term with the actively requested domain. I have built one store where this was a take-away after months of development.
- I recommend https://www.drupal.org/project/entity_translation for field level translation
- You will still likely need https://www.drupal.org/project/i18n for menu and taxonomy (attribute) translation.
- I highly recommed you tell your designer you need an interface that helps selecting a domain, a language, and a currency. Or some combination. At the end of the day, there isn't one easy way to do this, especially important to nail the mobile-responsiveness of your visual solution. (Drop-downs don't make as much sense on a phone).
