That's funny xD, thanks for replying.

Thanks for the feedback!

On "Repository + DTOs only": That works for small projects, but as you scale you'll face:

Where do complex reports go? (not CRUD) How to avoid 50-method repositories? How to prevent query duplication?

MDA's Finder/Query/Action separation solves this before it becomes a problem. On Filament: I haven't used Filament myself, so I can't speak from experience on integration patterns.

PS: Documentation was recently updated with more examples and Use Case patterns—worth checking out!

Great point! MDA definitely won't magically fix team behavior—no architecture can. But I think there's value in making the "correct" path the easiest one. It's like putting healthy snacks at eye level in the fridge: it won't force anyone to eat better, but it removes one barrier. DevOps culture is about collaboration and automation, which is essential. MDA addresses a different (but related) problem: "When I need to add a feature, where does the code live and how do I keep it maintainable?" Think of it as complementary: DevOps helps you deploy cleanly, MDA helps you organize what you're deploying.

Hey everyone I created MDA to solve a real problem in my company: developers organizing code differently across projects (some used repositories, others put everything in controllers, some tried DDD halfway...).

What is MDA?

An opinionated starter kit that organizes Laravel projects around models, with clear separation:

Actions, Finders, Queries, Repositories by model

Predictable flow: Controller → Service → (Finder/Query/Action)

Flexible, not dogmatic - adapt it to your needs

What it's NOT: Full DDD or "the right way" - just a practical guide for team consistency. Why share this? I know there's much I still need to learn. I'd love your feedback:

What problems do you see? What would you improve? How have you solved similar issues?

Docs: zangles.github.io/MDA/README.en

Thanks for your time!