6 ms·

you make a good point to keep things simple, "solve the problem you actually have not the one you wished you had". But, many of these ideas can have advantages

by shoo 5y ago

you make a good point to keep things simple, "solve the problem you actually have not the one you wished you had". But, many of these ideas can have advantages even in small scale contexts. In some contexts they're not wins (e.g. extreme performance requirements might be prioritised over cost of future change) but in most situations where the cost of abstraction is negligible they're not a bad idea. e.g. i've seen a gigantic technical mess created in a small company with less than a dozen staff -- that required a year of engineering effort to remediate -- because the application code of the company's product was not written to decouple the product's internal domain model from the external format controlled (and changed) by the first customer.

pydry 5y ago
Messes are obviously bad but I dont think these patterns are the answer. They typically balloon the amount of code in exchange for nothing more than a bit of consistency and the ability to write some fairly hollow unit tests. Hexagonal works where you have a big solid core of complex stateless business logic but thr fact that it's very common to NOT have this and hexagonal presents itself almost as a panacaea makes me hate it a little bit.
activitypea 5y ago
You're a 100% right with that example, I just think it's important to pry these apart as separate issues. The issues you faced should've been solved by a simple data transformation at the system boundary. "Don't let external data formats permeate through your codebase" is, to me at least, basic engineering intuition. There's no deeper meaning to be gleamed from that, the team lead displayed gross incompetence and now you have to clean up his mess. On the other hand, these "clean architecture" blogs paint this ungrokkable colossus as a northstar -- they contrast it with issues like yours, and present this as the cure to every problem you've ever had in software. I just don't think that's true. None of these blogs ever highlight the loss of understanding. As you approach this style of engineering, you have so many layers, dependency injections and "oh and btw also this" style cross-cuts that no single use-case i.e. codepath can be understood by single person. You're just writing small units of code and hurling them at the codebase, hoping they enter the black hole's orbit and do what you want them to. I like to think that's why Uncle Bob uses huge, unexplorable celestial bodies for book covers :) P.S. as a counterpoint to your example, I work at a company that's infatuated with the idea of microservices, with little consideration of the tradeoffs involved. A while back I had to add a feature to a new microservice that had been a few months in production. After a couple of weeks of wading through the ports and adapters, DDD-inspired architecture, I realized two things: one, this "service" is just exposing CRUD operations on a single database table with zero business logic in the middle. And two, the Data/ORM adapter layer of the architecture does not work. The migrations are never executed, the DB entities are never mapped, and SQL queryies never fire. Looks like nobody used it since it was first deployed :)
- deleted 5y ago
  [deleted]

by shoo 5y ago

pydry 5y ago

Messes are obviously bad but I dont think these patterns are the answer. They typically balloon the amount of code in exchange for nothing more than a bit of consistency and the ability to write some fairly hollow unit tests. Hexagonal works where you have a big solid core of complex stateless business logic but thr fact that it's very common to NOT have this and hexagonal presents itself almost as a panacaea makes me hate it a little bit.

activitypea 5y ago

You're a 100% right with that example, I just think it's important to pry these apart as separate issues. The issues you faced should've been solved by a simple data transformation at the system boundary. "Don't let external data formats permeate through your codebase" is, to me at least, basic engineering intuition. There's no deeper meaning to be gleamed from that, the team lead displayed gross incompetence and now you have to clean up his mess. On the other hand, these "clean architecture" blogs paint this ungrokkable colossus as a northstar -- they contrast it with issues like yours, and present this as the cure to every problem you've ever had in software. I just don't think that's true. None of these blogs ever highlight the loss of understanding. As you approach this style of engineering, you have so many layers, dependency injections and "oh and btw also this" style cross-cuts that no single use-case i.e. codepath can be understood by single person. You're just writing small units of code and hurling them at the codebase, hoping they enter the black hole's orbit and do what you want them to. I like to think that's why Uncle Bob uses huge, unexplorable celestial bodies for book covers :) P.S. as a counterpoint to your example, I work at a company that's infatuated with the idea of microservices, with little consideration of the tradeoffs involved. A while back I had to add a feature to a new microservice that had been a few months in production. After a couple of weeks of wading through the ports and adapters, DDD-inspired architecture, I realized two things: one, this "service" is just exposing CRUD operations on a single database table with zero business logic in the middle. And two, the Data/ORM adapter layer of the architecture does not work. The migrations are never executed, the DB entities are never mapped, and SQL queryies never fire. Looks like nobody used it since it was first deployed :)

deleted 5y ago
[deleted]