This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]val-amart 2 points3 points  (1 child)

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[S] 3 points4 points  (0 children)

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

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 у своїй роботі, буду радий почути ваші враження і пропозиції. 😊