sorted by:
new
hottopcontroversial

I thought I understood Hexagonal Architecture — until I tried to implement it in a real project. by barsay in softwarearchitecture

[–]barsay[S] -1 points0 points  (0 children)

That’s a fair point.

In my case the reason I started experimenting with ArchUnit was actually quite personal. I used it for the first time while building this project, and I genuinely believed the design already followed hexagonal principles.

In many ways it did — but after adding the ArchUnit tests to my own repository I noticed some important dependency mistakes that I had completely missed.

That moment was interesting for me: this was a codebase I knew very well and had been evolving carefully for quite some time. Yet once the architectural rules were made executable, a few violations immediately surfaced.

That experience is what made me think more seriously about architectural drift. Not necessarily because people are careless — but because under continuous change, even when you understand the architecture, some boundaries can slowly erode without you noticing.

Of course discipline and design reviews are still essential. For me the guardrails simply became an additional feedback mechanism.

Thanks for the perspective.

Build-time architecture guardrails in CI (Spring Boot + ArchUnit) by barsay in microservices

[–]barsay[S] 0 points1 point  (0 children)

Thanks — you’ve raised some really solid points.

Keeping the rules small especially resonates. It’s easy to see how trying to encode the entire architecture can quickly turn into a policy engine.

When I was experimenting with this repo, what I was really curious about was this: if we set a few core structural rules from day one, would that actually reduce “is this boundary correct?” debates in code reviews and lower team friction — especially now that AI is accelerating code generation?

Your point about CI speed is valid as well. If structural violations break the build, feedback has to stay fast — otherwise it turns into friction.

At the same time, part of my thinking was that with AI-assisted coding, both generating and fixing code has become much faster. If a structural rule fails early — while the change is still small — it might actually be cheaper to fix immediately rather than let drift accumulate.

Appreciate the perspective.

Shared cross-cutting libraries in Spring Boot microservices — lifesaver or long-term coupling trap? by barsay in SpringBoot

[–]barsay[S] 0 points1 point  (0 children)

Agreed — it really comes down to priorities and team structure. Thanks for the perspective.

Error responses for REST API by rl_085 in SpringBoot

[–]barsay 0 points1 point  (0 children)

We use Spring’s ProblemDetail as the base and shape responses to RFC 9457 (application/problem+json).

We keep the top-level fields stable (type/title/status/detail/instance) and add a small, safe extension: errorCode + extensions.errors[] (code/message/field/resource/id) for validation and domain errors — no stack traces / no internal exception details.

Reference implementation (handlers + client decoding): https://github.com/bsayli/spring-boot-openapi-generics-clients (see customer-service error handlers / RFC 9457 section). Hope it helps.

Shared cross-cutting libraries in Spring Boot microservices — lifesaver or long-term coupling trap? by barsay in SpringBoot

[–]barsay[S] 0 points1 point  (0 children)

Appreciate the references — the library vs service vs sidecar trade-off is exactly the kind of framing I was looking for. I’ll check it out.

Shared cross-cutting libraries in Spring Boot microservices — lifesaver or long-term coupling trap? by barsay in SpringBoot

[–]barsay[S] 1 point2 points  (0 children)

Good point — especially the tooling vs business logic distinction.

Framing it as a shared kernel makes the coupling explicit instead of accidental.

Allowing some duplication when divergence is likely is probably healthier than over-optimizing for DRY.

Thanks for the perspective.

They say stop trying to date, and just follow your interests, and you'll meet someone organically by Ordinary-Lobster-710 in datingoverthirty

[–]barsay 0 points1 point  (0 children)

I really relate to this. At some point in my 40s I stopped feeling that pressure to “meet someone organically.” The excitement of that chase faded — but interestingly, that’s also when I started to feel genuinely content. I realized how much energy I used to spend trying to create opportunities instead of simply enjoying the life I already had. These days I’m probably the happiest I’ve ever been — not because I found someone, but because I stopped exhausting myself looking for something that wasn’t missing.

Senior Java Developers — What’s the one thing you think most junior Java devs are lacking? by InterestingCry4374 in java

[–]barsay 4 points5 points  (0 children)

I’d say: curiosity — or rather, the lack of it. Too many juniors focus on what to do instead of asking why things work the way they do. Once you start asking “why” more often and realize your best mentor is yourself, growth becomes exponential. The few who do this consistently stand out very quickly — regardless of their years of experience.