This is perhaps a case where miscommunication saved an entire industry.

I once got a new hire from Uber and for months on end his complaint was that “the services are too big”.

I once wrote a small class at work and by the time I left it was like over 8k lines long. People jokes it was my fault I called it HelperUtil instead of something more descriptive. It was a dumping ground for all the stuff people didn't want to think about. I wonder if something like that is possible in the microservice world?

▲

mattmanser 4 days ago | parent | next [-]

It probably wasn't a joke. If you call something HelperUtil, it will become a dumping ground. That's a learnable lesson around naming, a mistake, but it's not learnable if it keeps getting described as a joke.

C# accidentally solved this problem with extension methods, these little helper utils at least get grouped by type and not in one humongous file. Or maybe that was part of the design team's intention behind them all along.

And because they're static you can easily see when services or state are getting passed into a method, clearly showing when it should in fact be some sort of service or a new type.

	▲	XajniN 3 days ago \| parent [-]
		You’ve never seen `public static class Extensions` in a project named Something.Shared?

▲

whstl 3 days ago | parent | prev | next [-]

In the microservices world this is the monolith itself sitting in the center :/

Even in architectures that start as distributed, I’ve seen the “involuntary monolith” arising.

Way too common, unfortunately.

▲

ssdspoimdsjvv 4 days ago | parent | prev [-]

Of course, it just becomes the HelperUtilService!