2 ms·

It's a lot easier to violate that when it's just an import and a call away. I will concede that if the system is well designed and developers follow the pattern

It's a lot easier to violate that when it's just an import and a call away. I will concede that if the system is well designed and developers follow the patterns set it doesn't matter if it's a microservice based architecture or not.

mumblemumble 6y ago
I suppose it depends on your language. For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, on the other hand, you're working in Java 9 or later, you have the ability to control your public interface. People can get around that with reflection, so it's technically more permeable than a service boundary, but, if you're letting shenanigans like that sail past code review, you get what you deserve.
- 100011_100001 6y ago
  Perhaps the dev culture I am in is skewing my perspective. There have been developers that have changed private methods to public just so that they can access them. You make a good point, it's a code review problem and by extension Architecture teams not communicating effectively with Dev Leads.
  - rowland66 6y ago
    I agree, and packages and package private access is such a powerful tool in Java, that so many developers completely ignore.
    - mumblemumble 6y ago
      Largely because it's not that powerful. It's got several shortcomings, but the main one is that Java doesn't actually understand Java package organization conventions. To Java, "com.mycompany.stuff" and "com.mycompany.stuff.specialized" are two completely unrelated packages, and so stuff that's package-private to "com.mycompany.stuff" is inaccessible from "com.mycompany.stuff.specialized". That and a few other details make the feature annoying enough to use in practice that most people just find it's better to just stop using it. Fortunately, if you're on Java 9 or later, there are modules, which are a much better fit for what kinds of access control tooling programmers actually need.

mumblemumble 6y ago

I suppose it depends on your language. For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, on the other hand, you're working in Java 9 or later, you have the ability to control your public interface. People can get around that with reflection, so it's technically more permeable than a service boundary, but, if you're letting shenanigans like that sail past code review, you get what you deserve.

100011_100001 6y ago
Perhaps the dev culture I am in is skewing my perspective. There have been developers that have changed private methods to public just so that they can access them. You make a good point, it's a code review problem and by extension Architecture teams not communicating effectively with Dev Leads.
- rowland66 6y ago
  I agree, and packages and package private access is such a powerful tool in Java, that so many developers completely ignore.
  - mumblemumble 6y ago
    Largely because it's not that powerful. It's got several shortcomings, but the main one is that Java doesn't actually understand Java package organization conventions. To Java, "com.mycompany.stuff" and "com.mycompany.stuff.specialized" are two completely unrelated packages, and so stuff that's package-private to "com.mycompany.stuff" is inaccessible from "com.mycompany.stuff.specialized". That and a few other details make the feature annoying enough to use in practice that most people just find it's better to just stop using it. Fortunately, if you're on Java 9 or later, there are modules, which are a much better fit for what kinds of access control tooling programmers actually need.