Modularization - Restrict imports in gradle to a specific package to ensure hexagonal architecture boundaries about banking-kata-java

[schneidersteve]

As an alternative solution i would recommend gradles support for multiple components/projects instead of one component with a deep packages structure.

https://docs.gradle.org/current/userguide/structuring_software_products.html#structure_large_projects

[valentinacupac]

I plan to work on this topic, as preparation for an upcoming meetup. Some changes I had made up to now was separate unit tests from integration tests (i.e. separate fast running from slow running), but next I need to actually also modularize the architecture too.

The following is a rough plan of what I'm currently doing (in progress), I see this as the minimal split required: core & adapter-*

[valentinacupac]

@nicolasrosado, @schneidersteve I've added the split via modules core and adapter-*. In this way, all the infrastructure is purely within adapter modules. Interested to hear your thoughts.

@schneidersteve, in my current code, I'm using modules, but it's still all a single build. I saw the link you sent Reflecting software architecture in project structure - "We can represent each of our components as a separate Gradle build." - what do you see as the pros of that approach, compared to just the single-build multi-module approach?