Hacker News new | past | comments | ask | show | jobs | submit login

I've come to believe that strong conventions matter a lot more than specific patterns because of stuff like this.



But... what the OP writes are strong conventions, no?

Coming from Spring or Java EE:

> implementations that could literally be a lambda function (on receive message, write row into DB) are a festival of multiple tiers of objects, mappers, mediators, IoC frameworks, wrappers, Nuget packages, etc., etc.

Spring or Java EE is a strong convention, so IOC is one automatically as well (both make use of that heavily). Hibernate would be the next strong convention, therefore mappers are, therefore we will have multiple tiers of objects. Wrappers will also be needed in a language like Java. About the rest of this list I can't say much now, but I would argue that lots of what this person is doing is based on strong conventions in the enterprise world. And it goes on:

> Everything is in multiple projects. Simple constants (like: API routes - '/api/foo/bar') are indirected into files containing those strings, so there's a huge cognitive overhead and much clicking around to make sense of it. God help you if you don't use an IDE.

Coming from Java again, everything won't be in multiple projects, but in multiple Maven modules instead. AFAIK that is good practice, or, if you want: a strong convention. Stuff like API routes will indeed not be saved in a code file, but in an openapi file instead.

IMO then, what this person was doing was actually following strong conventions. Yes, these are often also specific patterns, but what is the difference, specifically for these things listed here?

It seems to me much more that the person was probably "limited" more by the language. I think there are fairly good reasons for all of these, especially when working with more than ten people - in a language like Java. And in this case you will have to use Java (or something similarly famous) because otherwise you won't find a replacement very quickly that is fairly cheap. Now, maybe the person would not have needed all this in such a small project that is just for one person. But who knows, maybe the project grows. Or maybe this person was simply familiar with this and could get this down fastest. All in all, I think there are many good reasons to decide to make a project with patterns/conventions like this.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: