Maintain a clean architecture in Python with dependency rules

This (plus Law of Demeter) is the right way to handle medium-big size projects, though I&#x27;m not completely sold on the tooling. I mostly do it manually (yes, it is still doable with dozens of modules since dependency hierarchy doesn&#x27;t change often).<p>One recommendation I have is to present the hierarchy as DAG. Existing image (<a href="https:&#x2F;&#x2F;sourcery.ai&#x2F;static&#x2F;05300f06cb847360719e2aa31dc5a31b&#x2F;8c857&#x2F;dependencies.png" rel="nofollow">https:&#x2F;&#x2F;sourcery.ai&#x2F;static&#x2F;05300f06cb847360719e2aa31dc5a31b&#x2F;...</a>) doesn&#x27;t make it very obvious that api is a highest-level module, even though it is clearly stated in the rules.

Before clicking on this, I expected to see import-linter [0] which achieves something very similar but with, in my opinion, a bit less magic. Another solution in a similar spirit is Pants [1], though this is actually a build system which allows you to constrain dependencies between different artifacts (e.g. which modules are allowed to depend on which modules).<p>To Sourcery&#x27;s credit, their product looks much more in the realm of &quot;developer experience&quot; -- closer to Copilot (or what I understand of it) than to import-linter. Props to them for at least having a page about security [2] and building a solution which doesn&#x27;t inherently require all of your source code to be shared with a vendor&#x27;s server.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;seddonym&#x2F;import-linter" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;seddonym&#x2F;import-linter</a><p>[1] <a href="https:&#x2F;&#x2F;www.pantsbuild.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.pantsbuild.org&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;docs.sourcery.ai&#x2F;Product&#x2F;Permissions-and-Security&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.sourcery.ai&#x2F;Product&#x2F;Permissions-and-Security&#x2F;</a>

After dealing with that problem and enduring the pain of it for years, I finally switched to C#&#x2F;.NET. It has the necessary tooling to achieve this and more.<p>Rewriting a lot of things was time well spent rather than trying to tame the dynamic nature of Python and my tendency to overuse it.<p>And I can&#x27;t believe I&#x27;m writing this after all these years evangelizing Python and dynamically typed languages.

I do exactly this in my side project. I have a set of rules which put restrictions on which packages and modules can be included from other packages and modules. For example, a high maturity package is not allowed to depend upon a low maturity package. Similarly, a core library package is not allowed to rely on a package that is specific to a particular product or a particular piece of bespoke development. In this way, much of the potential for circular dependencies is eliminated, and the purpose and internet is clearly communicated.<p>(I don&#x27;t do this using sourcery though ... I have my own set of rules)

&gt;While Python doesn&#x27;t allow circular dependencies between modules, it won&#x27;t stop you from introducing circular dependencies between packages.<p>Just to nitpick, while it is a very potent foot-gun, Python absolutely does allow circular dependencies between regular modules; here&#x27;s a good write-up about this:<p><a href="https:&#x2F;&#x2F;stackabuse.com&#x2F;python-circular-imports&#x2F;" rel="nofollow">https:&#x2F;&#x2F;stackabuse.com&#x2F;python-circular-imports&#x2F;</a>

Am I only person that prefers to use raw SQL over of SQLAlchemy? I do not see any real advantage of using SQLAlchemy over raw SQL if I do not plan (which I do not plan) in future to switch DB engine for the application. Do you see any real advantage of using SQLALchemy over raw SQL queries if you do not plan to switch DB engine for your application in future?

A follow-up post: <a href="https:&#x2F;&#x2F;sourcery.ai&#x2F;blog&#x2F;dependency-architecture&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sourcery.ai&#x2F;blog&#x2F;dependency-architecture&#x2F;</a>

I&#x27;ve already seem tools like this for other languages, but never seen someone effectively using them. Does anyone here has good or bad experiences with these architecture rule systems?

Is there anything similar to this for Java&#x2F;Kotlin&#x2F;Gradle?

This is supported in Bazel with package visibility rules. Once you&#x27;ve got that feature as a way to tame a larger and expanding codebase, you&#x27;ll wonder why it isn&#x27;t a feature in more systems.<p><a href="https:&#x2F;&#x2F;bazel.build&#x2F;concepts&#x2F;visibility" rel="nofollow">https:&#x2F;&#x2F;bazel.build&#x2F;concepts&#x2F;visibility</a>

Is there something like this for react&#x2F;jsx? I always wished I could constrain component dependencies across the atom &gt; molecule &gt; organism layers.

In Typescript, i normally just allow interface to be dependencies between layers. (API, command line programs,..) -&gt; (Services) -&gt; (Database).

Your DB &#x2F; api layer should never touch the same models.

Title is misleading, it should be &quot;Maintain a clean architecture in FastAPI with dependency rules&quot;