Hacker News Reader

Comment by CraigJPerry | Hacker News Reader

This is java circa 2009 flavoured, this model was a popular approach in the java community around that timeframe. Was enforcer the name of the maven plugin? I can’t remember now, but it became fairly popular.

I wonder if this might be susceptible to the same issues that we had in java, specifically it doesn’t prevent accidental duplication, it makes refactoring harder/slower and it’s problematic for the team when it unexpectedly doesn’t catch a misuse - and this happens because the rules enforcement can only happen effectively if the rules themselves are perfect and complete and that gets harder to guarantee with scale and speed of iteration.

For my money today, there’s another model “polylith” which is similar in some ways and as easy to understand but maybe simpler to evolve/change your mind over time.

View on HN

> prevent accidental duplication

sometimes sections of code can be syntactically duplicate at some point in time but aren't really semantically duplicate.

e.g. in terms of the example in the post, of having different client-specific logic. at times two different clients may end up with syntactically duplicate code in their corresponding client-specific layers. but unless this code reflects that some detail specific to both clients is actually subject to the same pressures and constraints, what is syntactically duplicate today may not be tomorrow when client A's code needs to change due to pressure P that does not also impact client B, so the syntactically duplicate code is no longer syntactically duplicate.

factoring out syntactically duplicate common code between things that need to change at different times for different reasons is unhelpful as it introduces unnecessary coupling.

not sure if i've understood the context of "prevent accidental duplication" but reasons for change and avoiding unnecessarily coupling is something that jumps into mind when considering multiple clients or multiple regions

Maven Enforcer does have a rule for duplicate class _names_ (which includes the entire namespace), but I think the author was more talking about it's enforcement of duplicate dependencies. For example, it will detect when you have different (transitive) versions of the same library referenced by your code or dependencies.

> this happens because the rules enforcement can only happen effectively if the rules themselves are perfect and complete and that gets harder to guarantee with scale and speed of iteration.

IMHO, project-level assertions about initialization-order feels a little bit dirty, but potentially practical as long as there's only a few rules. Surely even a bazillion line monolith can still often be thought of in terms of a few layers. But by the time you get to lots of rules it's getting hard to stomach the code-smell and keep justifying it as practical. At that point I'd want something dynamic and backed by a real solver.. not just a layer of static-analysis.

The deal framework for DBC doesn't quite do this afaik but is starting to expose some stuff along these lines, and at least can assert imports are "pure". https://deal.readthedocs.io/details/module_load.html

Have you had any experience using deal on personal projects or professionally yet?

So far I'm working it into personal projects gradually. Runtime checks are at least as useful as something like pydantic's validation, and more expressive, because validation is basically "pre" but now deal can provide the "post". DBC via pre/post might be "just" syntactic sugar on asserts, but notation matters: it looks great, it reduces cognitive load. It easily does stuff that's impossible or just awkward with types, so having an alternate way to express constraints available probably keeps me out of certain rabbit holes.

Really looking forward to trying verification ( https://deal.readthedocs.io/basic/verification.html ) but I think I need to hit some critical mass of annotation first.

You can see duplication in the one example they provide —- between clients and territories.

Every client has to have duplicate modules for every territory that they operate in and if they begin to operate in another territory, that has to be copied in — or they have to keep a copy of all territory modules for every client. I think it is probably the former, since they talk about pruning and ignored imports.

polylith ftw.

Been learning some of the idioms of a polylith architecture using the `poly` tool + clojure. Really enjoying the idioms/practices it encourages.

What is the current flavor in Java?

Spring (and all its reflections under the hood), of course.

Reply on news.ycombinator.com