Model Domain Architecture (MDA)

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!

vincent15000

4 months ago

Level 63

I'm not sure that a simple starter kit can really change the behaviors of dev teams.

What you are describing let me think about the DevOps culture as a solution to your problem.

[email protected]

4 months ago

Level 1

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.

1 like

king-bcolor

4 months ago

Level 1

A good approach. Some have tried DDD but only halfway through, which is correctly pointed out. However, is it still too complex? Would it be faster if we only used the Repository pattern and DTOs, rejecting the encapsulation of complex queries and replacing them with multiple simple queries, using them as needed to avoid an explosion of query objects? But a more pressing concern is how to elegantly apply this in Filament. The Repository pattern and DTOs are definitely suitable for splitting a task between two AI agents, allowing both agents to operate without concerning themselves with each other's specific behaviors.

1 like

[email protected]

4 months ago

Level 1

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!

1 like