Groping in the dark as a method to discover module boundaries in microservices

I’m not sure that we will ever have a better way (but then, we can never pretend to be like other types of engineers, can we?):

Having clients talk to the application service instead of an ORM or the
data backends directly lets you forget that there is a MASSIVE PROBLEM with
ORM frameworks (for anything more interesting than, say, a blog website
framework), because you will still have to write a translation between your
application representation and the database representation. This is
probably the most tedious part of writing the whole system — but if you
don’t do this you will wind up re-inventing every bit of the transactional,
relational, navigation-capable, document and object database paradigms all
mishmashed together into an incoherent, buggy, half-baked API without
realizing it (until its too late to change your mind, that is… *then*
you’ll certainly realize it).

DON’T REINVENT THE DATABASE.

But you’ll do this once, no matter what I say. Anyone who architects and
then implements two huge systems does this once (either the first or the
second time). And then realize that an application-service-as-a-datasource
can be a very fast, nice thing, and that databases are magical tools that
you’re really, really glad someone else went to the trouble to write.

Also — none of this *solves* the distributed state problem. But there is
hope! As you write systems you’ll start feeling out places where it is OK
to partition the problem, where temporary inconsistency in the cached data
is OK (and where not in the backend datastore), how much write lag is OK
between the application service and the backend, what sort of queries are
pull-your-hair-out hard or slow or slow-and-hard without a specialized
database (hint: text search, image search and graph queries), and other
such issues. Also — what data is just OK to disappear POOF! when something
goes wrong (ephemeral chat messages, for example).

Its a lot to think through, and whatever tradeoffs you decide fit in
specific spots are going to depend entirely on the problem you are trying
to solve in *that* part of the system and the user-facing context. This is
true in any language and any environment. Anyone who says differently has
only ever dealt with trivial data or is a big fat liar trying to get some
magical consultancy cash from you.