3 ms·

What a useless crap. It’s an over engineered documentation framework focusing on all the wrong things so some agile consultant can sell more cool aid. I don’t t

by ahoka 3y ago

What a useless crap. It’s an over engineered documentation framework focusing on all the wrong things so some agile consultant can sell more cool aid. I don’t trust anything that is designed someone who last did real projects in the 2000’s OOP Java enterprise craze.

mkl95 3y ago
It's not a hard science. Take the parts that work for your team and scrap the ones that don't.
- politelemon 3y ago
  This is the important bit. C4 in its entirety isn't useful to many orgs and teams, and can be unnecessary overkill. You might end up picking 1 or 2 layers for yourself. You don't have to stick to their software either, use DrawIO if that's what you prefer, but understand the main concepts that C4 is trying to impart about the separation, what goes on the arrows, and how useless icons can be.
- npsimons 3y ago
  > Take the parts that work for your team and scrap the ones that don't. Precisely. Any time someone utters the descriptor "best practice", at best, you do yourself a favor by examining it with a critical eye and judge whether it is a good practice to follow (and a good fit for your project) or not. At worst, you beat back the consultants framing it as "the one and only way to do things (with the implication that everything else is wrong)."
- happytiger 3y ago
  The voice of reason always comes from the trenches.
lwhi 3y ago
I don't know whether your comment is useful or not because all you're doing is ranting and providing personal opinion. Your comment is useless to me; so ultimately I'm not likely to give it any credence.
arcbyte 3y ago
It's 4 diagrams. You can't get much less engineered than that. Whats your background that you have simpler alternatives?
lionkor 3y ago
So so much agree with this. People who think in terms of OOP and design patterns (i.e. bandaids) will think "how else are you supposed to model solutions"? But yes, this is fundamentally an OOP thing, and especially the component layer is very much just fantasy. In no real OOP software do these meat reusable components not have super strong binding to each other. Yeah you may have the SignIn controller and the ResetPassword controller both talking to the SecurityComponent, but in the end that's guaranteed to be implemented in such a way that you cant use any of them without all the others connected, and its likely that testing this means writing a mock for each of them that is so complex it may as well have its own tests. They are thinking of their problem, and building their solution entirely out of blocks made from the words that make up the problem. "We need users to be able to sign in and reset their password" becomes SignIn component and ResetPassword component, when really this is just a matter of changing a hash and possibly some encryption keys, and could just be a handful of validate(), reset() et al functions on the security module.
- lwhi 3y ago
  Architecture covers the macro, not the micro.

by ahoka 3y ago

mkl95 3y ago

It's not a hard science. Take the parts that work for your team and scrap the ones that don't.

politelemon 3y ago
This is the important bit. C4 in its entirety isn't useful to many orgs and teams, and can be unnecessary overkill. You might end up picking 1 or 2 layers for yourself. You don't have to stick to their software either, use DrawIO if that's what you prefer, but understand the main concepts that C4 is trying to impart about the separation, what goes on the arrows, and how useless icons can be.
npsimons 3y ago
> Take the parts that work for your team and scrap the ones that don't. Precisely. Any time someone utters the descriptor "best practice", at best, you do yourself a favor by examining it with a critical eye and judge whether it is a good practice to follow (and a good fit for your project) or not. At worst, you beat back the consultants framing it as "the one and only way to do things (with the implication that everything else is wrong)."
happytiger 3y ago
The voice of reason always comes from the trenches.

lwhi 3y ago

I don't know whether your comment is useful or not because all you're doing is ranting and providing personal opinion. Your comment is useless to me; so ultimately I'm not likely to give it any credence.

arcbyte 3y ago

It's 4 diagrams. You can't get much less engineered than that. Whats your background that you have simpler alternatives?

lionkor 3y ago

So so much agree with this. People who think in terms of OOP and design patterns (i.e. bandaids) will think "how else are you supposed to model solutions"? But yes, this is fundamentally an OOP thing, and especially the component layer is very much just fantasy. In no real OOP software do these meat reusable components not have super strong binding to each other. Yeah you may have the SignIn controller and the ResetPassword controller both talking to the SecurityComponent, but in the end that's guaranteed to be implemented in such a way that you cant use any of them without all the others connected, and its likely that testing this means writing a mock for each of them that is so complex it may as well have its own tests. They are thinking of their problem, and building their solution entirely out of blocks made from the words that make up the problem. "We need users to be able to sign in and reset their password" becomes SignIn component and ResetPassword component, when really this is just a matter of changing a hash and possibly some encryption keys, and could just be a handful of validate(), reset() et al functions on the security module.

lwhi 3y ago
Architecture covers the macro, not the micro.