how do folks feel about this approach: https://handstandsam.com/2018/02/11/kotlin-buildsrc-for-better-gradle-dependency-management/ i’ve always ensured that there is only a single version of all my dependencies (generally using the

io.spring.dependency-management

plugin in the root project) and versions stored in

gradle.properties

We've been using something like it even before Kotlin. It was not in buildSrc, but in an included groovy gradle script. We have since migrated to buildSrc as part of moving to kotlin-dsl. Currently it's kind of weird, because we also use spring dependency-management. I have a plan to look into unifying everything in the future, but I don't have any concrete recipes at the moment. There are many things with higher priority for us currently and time is not a stretchy thing unfortunately 😄

I’m using a

Versions

object in

buildSrc

for versions. I don’t see any value in something like

Libs

or

Deps

over just writing the dependencies in the

build.gradle.kts

file, so I’m not doing that.

sure, for single project i think that totally makes sense, for multi-module projects, i think it’s nice to have IDE support for adding previously-defined dependencies

I don’t see any value in multi-module projects 😛

architecture enforcement 🙂

I just have multiple projects

ah, that works too, though, if they’re not meant to be consumed by more than a single app, i don’t like to have to touch multiple repos

I agree with Ben here, we have a large multi-module project and having autocomplete for libs helps a bit. Another thing is that when adding new dependency we sometimes document as to why and what for, and Ctrl+Q is there for us 🙂 As we have several development teams which are geographically separated from each other, that's nice. @ribesg to each his own, for us multi-module works best 🙂

e.g. my build is modules:

web/
service/
repository/
domain/
common/

Well I guess this applies to big companies. For me the rule is just “don’t be stupid”

And now that we have Kotlin and

internal

, multi-module is even more helpful 🙂

Sure, I’m missing

package

. But code review and not hiring bad developers is enough to prevent people from doing crazy things

ya, i wouldn’t use multimodule on a very small 1-2 person team, but when you’ve got a dozen developers coding, having tools to enforce the architecture becomes very important imo

At some point having good developers stops working just on its own. E.g. when the project is 1.5MLOC and you have 5-6 separate teams working on it in parallel, while living in different countries and timezones 🙂

that just means it’s time for microservices 🤣 instead of one free-for-all codebase you could have 30!

Exactly. I worked at HP before the big split and it was a mess. Now I’m in a not-that-small startup in a 2-person team. I think that for projects with a lot of code multi-module would make sense, but we don’t do that. We try to split things into smaller projects talking to each other. Think micro-services but think more than backend.

Also when working with several juniors on the team, you get tired of fixing simple stuff during code review, which could've been avoided by implementing some restrictions once in the beginning 🙂

I feel like the answer to junior mistakes is more code review than project structure

I disagree, microservices are not warranted here, monolith is easier to manage, has simpler infrastructure requirements and requires less resources. The software while complex, is well modularized, has more or less well defined interfaces and is scaleable enough for what we need as a business. We'd have to rise our userbase by several orders of magnitude to warrant additional complexity of microservices.

Sure, but the knowledge needed to setup a multi-module project... It’s maybe a better solution when you have engineers dedicated to build

ya, in all my years of consulting i’ve just seen too many codebases doing too many weird things that could have been avoided with some architecture enforcement

Yeah no. You can’t just say using and not using packages is the same thing like that 😄 Something being accessible does not mean you should use it. A developer should be aware of the architecture of the project he’s working on, even a junior. And anything used in the wrong place would be easily caught on code review, imports are at the beginning of files

not necessarily, multi-module projects are not that hard with gradle, at least in my 3+ years on this project I have yet to hear a complaint about it 🙂

I just don’t feel like these kind of easily fixable issues required such hard solution. I guess it really depends on your environment and who you work with

and writing of automated tests can also be avoided by manual testing, but that takes time, as do code reviews, I'd rather setup architecture in a way which makes accessing wrong things from wrong contexts harder, than look for it each time I review a PR