Hi Sunderam,
In general, it's not bad advice. One of the biggest things that can go wrong is getting service boundaries wrong - it leads to higher cost of change, can lead to operation issues etc. We've found that an excellent way to find more stable, reusable/composable boundaries is to model them around the business domain. If your understanding of the business domain is poor (perhaps because you are new to it) the chances of you finding good boundaries early on is reduced.
I explore that a bit in a recent post
Microservices For Greenfield, which in part inspired Martin Fowler to write a related article
MonolithFirst - you might also want to look at Stefan Tilkov's
rebuttal too though to get a different view.
My general advice therefore is to be more cautious early on in a new project about spinning up lots of services. Some obvious boundaries may present themselves early on, but others might be less clear. So be more monolithic early. I do though think that even within the monolith,
you should strive to keep your code decomposed into modules oriented around business domains too (NOT arbitary technical domains). So rather than model, view controller packages, think Invoicing, Finance, Sales packages (inside which you may or may not then have technical groupings). Parnas FTW! This will help you if you decide to spin stuff out later. I explore that a bit in
the book (chapter 5) and also in my talk
Macro To Micro.
One last thought. Even when starting with a monolith, really question why you're using an application container. Why not bundle everything as an executable JAR file with an embedded
servlet container?