Hi,

Based on my understanding, both alternatives you mentioned would work properly, and I believe that design and structure of Modules would depend on the solution's complexity and each developer's design likes.

Nevertheless, you should notice that an extra communication between modules would be needed for the first approach. For example, you would need to use EventAggregator service in order to cache the tables in the ContactModule.

Using one only module for the lookup data feature instead, it would keep the search and database service tasks centralized, without the need of a loosely coupled communication. You would certainly manage and control the databases separately by defining different Views/ViewModels for a more firendly UI experience.

As I mentioned, you should define the module's scope by keeping in mind the reason of why each Module was defined and what set of features is packaging.

You can find more related information in the following MSDN Prism Guide chapter:

• 4: Modular Application Development
  

I hope this helped you.

Regards,
Gabriel Ostrowsky.
https://blogs.southworks.net/gostrowsky