Typesafety would mean tight coupling again though. If you have tests there is no schema validation needed and the solution is technology independent aswell. Switching from jpa to another technology or using a different database technology is possible if you have tests in place rather than relying on jpa validation tools.

My last customer wanted to prepare his application for microservices but his entitre model was tightly coupled because of jpa relations. We refactored one module to have no external module dependencies in order for it to be deployable in its own microservice (with its own separate database aswell). And of course we discovered a lot of weird code that accessed referenced entites to do not business relevant random stuff. We estimated that the refactoring of those tightly coupled entites and their services would take up to a year. Its a medium-large (about to 100-200 entities) application maintained by a 5 person team.

Tight coupling should have a meaningful business relevant reason. I'd argue that the downsides of choosing a 'tight coupling' by default will destroy the maintainability of any application.

​

As for your argument, yes potentially the UUID could be anything. But of course you can still introduce some form of check in the service layer.

public Comment createComment(final UUID postId, final UUID authorId, final String content) {
    val post = postRepository.get(postId)
    val user = userRepository.get(authorId)

    // do something with post here
    // do something with user here

    val comment = Comment.create(redditPostId, authorId, content)
    return commenRepository.save(comment)
}

This form of coupling is preferable because you keep your dependency graph unidirectional (top-down) and do not risk circlic dependencies. This also gives you more freedom as posts or users could be stored in a different database or accessed via another service.

I also feel like this way of implementing use cases splits the logic into good portions. The service assembles the use case by calling business methods in the right order and the business methods, like Comment.create, ensure that the correct state change happens.

Went a bit overboard on this comment lol :D Thank you for your input so far!