In short
Your core business logic shouldn't import web frameworks, ORMs, or do raw IO. This fails if a domain module imports things like flask, sqlalchemy, or requests.
Problem
Keeping the domain independent of frameworks and IO is a near-universal check that today requires spelling out each banned package by hand.
Proposal
A first-class domain-purity check building on the existing external-dependency rules, e.g. project_files("src/").in_folder("**/domain/**").should_not().depend_on_external_modules().matching("flask", "fastapi", "sqlalchemy", "requests"), ideally wrapped as a .should_be_framework_free() shortcut with an allowlist.
Acceptance criteria
- A domain module importing a banned package fails with the import path.
- Per-rule allowlist supported.
Reactions are currently unavailable
In short
Your core business logic shouldn't import web frameworks, ORMs, or do raw IO. This fails if a domain module imports things like flask, sqlalchemy, or requests.
Problem
Keeping the domain independent of frameworks and IO is a near-universal check that today requires spelling out each banned package by hand.
Proposal
A first-class domain-purity check building on the existing external-dependency rules, e.g. project_files("src/").in_folder("**/domain/**").should_not().depend_on_external_modules().matching("flask", "fastapi", "sqlalchemy", "requests"), ideally wrapped as a .should_be_framework_free() shortcut with an allowlist.
Acceptance criteria