Comparison with other tools

Tools similar to katachi include Konsist, ArchUnit, and others. They are not necessarily exclusive with katachi.

Comparison table

Tool	What it looks at	How it runs	Use with katachi
katachi	Whether a file may exist at all, and where it is placed	Unit test	—
Konsist	The contents of classes, functions, and properties, within a scope	Unit test	⭐️ Integrated / recommended
detekt	Static analysis of the source. Code smells and your own rules	Gradle task / CLI	🆗 Works
ArchUnit	Dependencies between classes and layers. JVM class information	Unit test	🆗 Works
ProjectGuard	Dependency declarations between modules. The build graph	Gradle plugin	🆗 Works
Konture	Module dependencies, package encapsulation, class characteristics	Unit test	🆗 Works

katachi is the only one that asks whether a file may exist. The other five all check the contents of, or the relationships between, things that already exist.

That is why they do not overlap. What does overlap is the other tools with each other: Konsist, ArchUnit, and Konture cover similar ground, and there is little point in adopting all three.

katachi and Konsist

Use together	⭐️ Integrated / recommended

Konsist narrows its target with Konsist.scopeFromProject() and checks the classes and functions inside that range. Anything outside the narrowed range is never checked. A file that strays from the naming convention, or a directory nobody anticipated, stays out of view.

katachi is the reverse: it scans the whole project and matches it against the declaration. Responsibility splits between “placement” and “contents”, so either one alone leaves something unchecked.

katachi bridges the two through an optional module called katachi-konsist. Write konsist { } inside a role and call assert(FileConstraintCheck()) in the test, and placement violations and content violations land in a single report.

ProjectArchitecture.kt

"UseCase" {
    // where it may be placed — katachi's job
    layout {
        "src/main/kotlin/com/example/useCase" / "*UseCase".ktFile()
    }

    // what its contents should look like — Konsist's job
    "has exactly one invoke function".konsist {
        classes().must { it.functions().map { f -> f.name } == listOf("invoke") }
    }
}

Ideas

You can turn the nature of a role directly into a constraint.

• A UseCase has exactly one invoke function — the definition of the role itself
• A Repository is declared as an interface — effective in a layer built around swappable implementations
• A role’s files are visible from the outside — classes().must { it.hasPublicOrDefaultModifier }
• A ViewModel does not reference Android view types — stop layer leaks from the contents side
• Classes in the data layer carry a particular annotation — keep serializable types from being missed

katachi and detekt

Use together	🆗 Works

detekt statically analyses Kotlin source and points out code smells and style deviations. Write your own rules and it can check project-specific conventions too.

Its unit of attention is the contents of a file, so it does not clash with katachi. katachi decides “this file may live here”; detekt looks at “how the contents are written”.

katachi has no detekt integration, but the division of roles works fine as it is.

Ideas

Sometimes it is unclear whether something belongs in detekt or in konsist { }. Two rules of thumb:

• If you want one report, use konsist { }. Checked with assert(FileConstraintCheck()), it comes out alongside the placement violations, so a single test run gives you everything you need to fix
• If you want it to apply uniformly across the project, use detekt. Conventions that are not tied to a role (function length, complexity, general naming rules) lose their meaning when written inside a role

What detekt is good at:

• Function length, nesting depth, cyclomatic complexity
• Leftover println and TODO()
• Banning specific APIs (project-wide ones)

Summary

• katachi is a tool that asks whether something may exist. The other five ask how the things that do exist should look
• These tools are not exclusive. Combine katachi with as many other tools as you have questions for.
• The overlap is between the other tools. You do not need Konsist, ArchUnit, and Konture all at once

Next steps

• Konsist integration … Learn how to write konsist { } and how placement violations and content violations end up in one report.
• FAQ … Understand the design thinking behind why a tool that checks every file in the project against the declaration is needed.
• Your first architecture definition … Add katachi to your project and try the split in practice.