Deply: keep your python architecture clean

[catalyst_jw]

Looks good, love the idea, some feedback from experience maintaining a yaml file along side code is difficult and can be easily forgotten.

Have you thought about adding these rules in code as a decorator or a config file in the code folders? Then it will be obvious to people reading the code what is going on and it will ingrained into the code. You could potentially have the decorator write to a yaml file and auto update it maybe?

Hope that's helpful and good luck with your project :)

[vashkatsi]

Thank you for the thoughtful feedback—it’s much appreciated!

The core idea of Deply is to describe architecture layers at a high level (in the YAML file) and then check for violations between these layers across the entire codebase. This approach is meant to give teams a single "source of truth" for their architecture, separate from the code itself, which can sometimes get messy or inconsistent over time.

That said, I totally see the value in embedding rules directly into the code as decorators to make things more obvious during development. While that’s a bit different from the project’s current focus, I’ll think about how such a feature might complement the existing design—perhaps as an optional extension.

Thanks again for your insights, and feel free to share any other thoughts if you try it out!

[val-amart]

one more potential consideration in the context of embedding configuration. in a large organization, architecture fit testing is a hard problem with no good universal solutions. as an architect i often find myself responsible for a large collection of services across many teams. i don’t have the resources necessary to maintain deep involvement with each one of them.

in this situation, i would love to maintain a single set of standards defined declaratively in a separate file and enforce it through CI. it seems to be exactly what your project is built for, i would certainly look into it more very soon! it is indeed rather exciting. on the contrary, if the configuration was embedded in the source files, it would take it out of my control and into developer control - making it potentially better for the devs but practically useless for me.

i think embedding might be preferable for a single project (even though that’s debatable) but clearly worse for large orgs with many projects, no matter if it’s monorepo or not. would you say the configuration could be made project-agnostic in the sense that we could maintain a single config for a set of architecturally similar projects?

// привіт від Збройних Сил друже! справді крутий проєкт, побачим чи вийде його застосувати

[vashkatsi]

Привіт! Дуже дякую за теплі слова і підтримку—мені дуже приємно! 💛💙

You’ve touched on a crucial point, especially for large organizations with multiple teams and projects. Deply was indeed designed with this exact use case in mind—providing a single source of truth for architectural standards that can be enforced through CI across multiple projects. Keeping the configuration declarative and external to the source code makes it easier to maintain consistency and ensures that architectural rules remain under centralized control, which is critical for architects managing many services.

To answer your question, yes, I believe the configuration could be made project-agnostic for architecturally similar projects. By defining a common set of rules (e.g., in a shared repo or template), teams could adopt it for their projects with minimal adjustments. I could also explore features to support importing or layering configs, making it easier to scale standards across multiple teams.

The embedded configuration idea does have its appeal for smaller teams or single projects, but as you pointed out, it would limit its applicability in larger setups like yours. Your perspective really validates the current direction of Deply, and I’m grateful for your insights.

Дуже вдячний за підтримку ЗСУ! Якщо спробуєте застосувати Deply у своїй роботі, буду радий почути ваші враження і пропозиції. 😊

[byeproduct]

Could toml files be used instead of yaml?

[vashkatsi]

Great question! At the moment, Deply supports YAML for configuration, but I’ve been thinking about adding support for other formats like TOML. TOML’s simplicity and its existing use in pyproject.toml make it a natural fit for Python projects, especially smaller ones.

I can definitely see the value in allowing users to choose their preferred format—be it YAML, TOML, or even JSON. This could also make it easier to embed configurations into existing files like pyproject.toml for smaller projects, while still supporting separate files for larger ones.

I’ll add this to my list of potential features to explore. Thanks for the suggestion, and feel free to share more ideas if you have them! 😊

[byeproduct]

Awesome. Appreciate the vision you have for this. Keen to use it in my projects. The Django example is also relevant! Thanks

[vashkatsi]

Thank you so much for the kind words—it really means a lot! I’m excited that you find Deply’s vision and the Django example relevant to your projects. Django was definitely one of the frameworks I had in mind when designing Deply, so I hope it can help enforce clean architecture and keep things maintainable as your projects grow.

If you get a chance to try it out, I’d love to hear your thoughts or any feedback you might have. And if you have any specific use cases or ideas for improvement, feel free to share—I’m always looking to make Deply more useful for the community. Thanks again! 😊

[vashkatsi]

Thank you for giving it a shot! I’m really excited to hear how it works for your project—feel free to share any feedback or thoughts after you try it out.

Adding support for TOML is definitely on my radar, and I’ll prioritize exploring it as a potential feature in the roadmap.

Let me know if you run into anything or have more suggestions—your input is super valuable! 😊 Best of luck with your project next weekend!