Many words and few to the point. tldr: This person likes build-tools (Google's Bazel) that can constrain dependencies to be used only by certain packages, and says this documents the project's architecture.
I've always thought of "architecture" as a high-level description of run-time behavior, not a set of compile-time dependency constraints.
I have worked with ProjectReference before. How is it different from expressing a cross-module dependency in a Bazel BUILD file?
But as I already said in two other comments in this discussion, ProjectReference would be equivalent to what I'm describing in the article, just using language-specific tooling. If you are breaking your solution into various projects and keeping them separate with cross-references among them, you are doing exactly what I was describing already.
> the build graph -- the very thing that BUILD files define -- is the best place to encode [dependencies] in a programmatic manner.
so the thing is that a BUILD file doesn't define the build graph, it approximates it -- the build graph is always defined by language-specific tooling and specifications
it's fine that the BUILD file is an approximation! that's as good as you can do, if you want to try to model dep relationships between heterogeneous languages
so when we're talking about the dep graph, "using language-specific tooling" isn't a detail you can brush aside, it's a core requirement for correctness, really
I've always thought of "architecture" as a high-level description of run-time behavior, not a set of compile-time dependency constraints.