This message was deleted.

Multi-projects is a good way to manage the different modules. They have examples to show you how a(or several) common shared plugins serve different application and these modules share an umbrella root projects. This is very convenient when the project size is small. It is GREAT if you want to do the debugging because all the source code share the same root project. However somehow when the size grows bigger then, at least I found, the compilation time become extremely long which will greatly affect your productivity. Then after the project getting mature, then I split them again into different independent projects

A long time ago, I remember GR8CRM, which had a similar design, but it hadn't been updated in years http://gr8crm.github.io

Unfortunately looks like it’s based on 2.4.5. I think I’m glad I never saw it before, since if we’d used it, we’d have needed to have migrated it to the latest Grails. 🙂

I agree with @gaolei An alternative to multi-project is to use plugins which gets you the same split, but you have to compile/deploy them on change, which you can do locally. The trade-off is that the plug-ins are precompiled and when working locally can be deployed to your local .m2. As for the source code if you set the build-up right it will include the source so when you deploy you can later pull in that plugin with its source for debugging. One of the projects I worked on had a multi-project build with a common core of about 700k lines of Groovy code, and the applications were about 50k to 150k lines of Groovy code and took between 8 and 12 min. to compile and run from a clean, or about 3 to 4 min. on restart with no changes. Grails and monliths have their place, but once they start getting too big then migrating to micro-services/services architecture, becomes attractive, but with its own trade-offs.

Thanks for the information, everyone! We are currently looking at taking the multi-project approach and then eventually migrating to micro-services. 🤞

With micro-services, it doesn't have to be an all-or-nothing thing. You can start small, and have a hybrid solution.

@Mike Saubier Grails framework is a great fit for plugin-oriented architecture, and Peter Ledbrook has written an article about this pattern. https://spring.io/blog/2010/06/01/what-s-a-plugin-oriented-architecture Before you start your microservices migration, I think you can give it a try. I've written a plugin that is a great way to help develop low-coupling, modular plugins. https://github.com/rainboyan/grails-plugin-dynamic-modules

@Michael Yan Thanks for the information!