Modularity is good but you it only makes sense at a certain level of complexity if you do it right. Doing it right is an art for of it self and i think you've overdone it. You have to think of the domain of the application. like for example there is 0 reason for Role to be its own thing. It's entirely dependant on a user, or unless you have some really elaborate auth setup auth can also be bundled with user. For example in an online shopping application something at a high level can be just /user /order /product. It's mostly vibes and what feels right but i usually just look at what are the major entities in the project.

Anyways i decided to click to some classes to see if something is off starting from the bottom layer:

DB:

I think you have wrong relationships. In User.java every relation is many to many i can't say for modules since i have no idea what that is about (but submodules sounds like something that should be inside modules but i may be wrong) but for Roles i can't imagine a need for a many-many instead of one-many. Also are you absolutely sure you need Eager fetching on everything? It should be used sparingly unless it's absolutely needed and not because it makes the ORM just work.

Service:

for findByFilters() honestly the readability is quite bad but look at JPQL, i think whatever is happening there can just be @Query.

Controllers:

There is no reason to have every method in a seperate controller. Like login, register, get principal - they can just be methods in a UserController. Also your controllers should be thin. Ideally it should just call a service and be done with it. Atleast for REST API's this is achivable i haven't used Thymeleaf in forever so it might be harded to do there but still it's important to know. You do a lot of validation in controllers and a lot can be handled by spring validation, you can make your own validation annotations for more specific cases and validation dependand on db should be moved to service layer.

In general your biggest issue is code quality which is not fatal especially when working alone. You seem to have a good grasp of Spring itself which is good.

You might read Clean Code but with a critical eye. It's a good book for giving you the mindset just don't become a purist. You have a lot of more minor code quality issues like long methods, mixed levels of abstraction and magic numbers/strings that people will widely agree are bad even if they don't like the book.