voter-application-core still depends on Spring framework... about hex-arch-kotlin-spring-boot

[dustinsand]

Hi clojj,

I appreciate the suggestions and I agree with you. The application-core was meant to be agnostic of technical decisions so having the dependency on Spring with @service was an oversight! Great catch.

Another option is to remove the spring dependency in application-core module and use the javax.inject annotations instead. Replace @service with @nAmed so the application-core remains technology agnostic, but still maintains compatibility with Spring's DI. I tried this and all the tests continue to function as normal. I'm still thinking about which is the right choice, this option or what you mentioned. Your thoughts?

Using the onionArchitecture() would be cleaner.

Please submit a PR in the meantime and we can both think about the above question.

Cheers,
Dustin

[clojj]

ok, I did not even think about CDI annotations!
These still would depend on frameworks implementing them, but it would be an improvement, yes.

For me, Kotlin beans DSL is a nice modern approach.
In this scenario, it works fine by just passing the service type as generic type. The service needs a repository, which in turn can use spring annotations. No problem there.

There may be different scenarios though, which may require different approaches.

[dustinsand]

Pushed the small change to remove Spring from application-core.

I'm interested in your suggestions, submit a PR and I'll take a look at what you have in mind.

[clojj]

I just realized that the Quarkus module depends on CDI.
Think I have to ponder about these domain services some more, and how they relate to these surrounding frameworks (which usually make heavy use of DI)

And, if it is functions + data all the way (think Ktor), DI may not even be an issue at all.

[dustinsand]

Ktor and Kotless are all great and valid frameworks to use too. I come from a background with a heavy investment in Spring so I like to show where possible where other frameworks can interoperate with Spring. Quarkus for example.

If greenfield with Kotlin is possible, agree Ktor, Kotless, Micronaut, Quarkus are all great options which don't need Spring.