174 tables are quite a lot - more than Liferay itself brings. I'd recommend to spread out your application into separately deployable plugins - they don't (technically) need to be in the same plugin, service builder allows you to use the services across different plugins.
Proper dependency management should help you to isolate the functionality that you'll extract into separate applications. Declare which application needs which other application deployed before, and you can access the services cross-context.
To answer your comment-question, sampling with only two projects: Create them, both with service-builder. Let's call them common-portlet
and app1-portlet
. Obviously, app1-portlet uses components (and services) from common-portlet
.
In app1-portlet, edit docroot/WEB-INF/liferay-plugin-package.properties
and add the line
required-deployment-contexts=common-portlet
This will make sure that app1-portlet
is only deployed when common-portlet
is available. Also, common-service.jar
, the API of common-portlet
, generated with service-biulder, will automatically be put on the classpath of app1-portlet
, in other words, you can call the services that you implemented in common-portlet
.
Assuming your more abstract portlets have a more stable interface (typically this indicates a proper architecture), changes to app1-portlet
(or app2-portlet
etc.) will only affect the portlet where you make a change in. Even if you have a change in common-portlet
, service-builder will be relatively quick, however, on interface changes you still need to recompile everything, but that's the nature of dependencies. If you don't change your interfaces, you'll only need a redeploy.