I wish the author discussed microservices in the context of domains and models. If you model your application and find a distinct isolated domains, then consider creating separate services for them.
But again, why? Making them services means distribution and that has a cost. You must have some reasons to make them distributed. You should first consider simply having the isolated domains as modules in your application monolith.
It doesn't have to be: you can use (Ruby) modules, classes and namespacing to split the application into logical pieces. Then start to enforce encapsulation between these pieces, so all access to a given piece of the system goes through a small, well defined and documented interface.
If you are thinking about migrating to microservices at some point, it's also beneficial to try to limit the areas of the database schema that each of these pieces accesses. There's no point having lots of microservices running over the top of a single monolithic database schema: extracting microservices should imply extracting the relevant part of the database schema and putting it into a private database with operational access only through the microservice. You can make this much easier while still working in a monolithic application by being more disciplined about how much of the schema a piece of the application needs to know about.
Module is an overloaded term in software engineering. The most generic definition is just some bunch of code packaged somehow with a well defined interface.
