We've got one (really) big monolithic codebase that, over the years has implemented tooling that accidently looks a lot of what you're doing with Spring Modulith.

We've chosen a microservices architecture to isolate certain legacy dependencies (like SOAP) that have caused migration pains in the past.

Some customers struggled with drawn-out releases. Moving to ms let teams work trunk-based instead of hiding behind feature flags and long-lived branches.

Is the wifi on your cell stable when moving from room to room?

The single uppercased character is an Oracle naming convention if I'm not mistaken

We did this too, but then got stuck having to write endless mapping code from/to JPA. You have to keep detached objects/flushing/versioning in mind at all time.

I agree, at customers that use hexagonal we've had endless discussions about different hexagonal flavors.

But I must say that the idea that port implementations can't use all of the domain never came up 😅 Things just wouldn't work otherwise.

Well, "personally" I use package-by-feature and place port implementations and primary adapters as sub-packages. It works great with Java's access modifiers. If only I could mark the port implementations as "internal" to the parent package, things would be perfect 😅

Primary ports control access to business logic for primary adapters (Rest, UI, ..). Secondary adapters (repositories) need direct domain access.

I personally don't explicitally make primary port interfaces, I just call the application service methods.

I’m not sure I get your point. Are you saying that, for example, domain public methods are exposed to adapters that shouldn’t call them?

If not, I think you’re interpreting the literature differently than I am.

Repositories must have direct domain access to function.

I'm a bit confused, repositories return aggregates. If the repository implementation couldn't access domain types, it wouldn't be able to rehydrate them.

The connection to the port just marks interaction points.

The ports just define contracts, not the dependency rules. All layers depend on the domain layer, so value classes are valid dependencies anywhere in the hexagon.

I'm not sure I follow. A value object in the domain can be used by repository implementations.

I think having product teams doing projects is fine. But project teams that jump from product to product keep losing ownership

Those personal projects are relaxing though. Start several, finish none without consequences.

I also find the split between domain and event rather awkward.

High cohesion would mean service+domain+commands+events+ports on the root package for the aggregate, right?

Events can fit compact as records under a (sealed?) interface.

Package protecting mutating domain methods is also a big plus

That was a great read!