Use D-MVC Pattern in Symfony Application
Tags: symfony, mvc, softwaredesign, architecture
Published: 2022-07-24 11:44:43

---
title: Use D-MVC Pattern in Symfony Application
published: true
description: Another lightweight design solution for thinking in domain design
tags: symfony, mvc, softwaredesign, softwarearchitecture
cover_image: https://stringydingding.com/wp-content/uploads/2020/01/20C99A3F-45ED-4A8F-9DB3-53CBA12C26C8-scaled.jpeg
---

## 🗣 Our story 
This is about the journey to a **lightweight software design** for a complex conference management system.

The story started with:
> I am going to design a conference management system. It should contain different domains: user management, tweets and rating, schedule talks, registration & SSO. The development should take the domains into consideration.

See the design overview of conference management system

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l2321a9o2ctbkto0ycki.png)

## 🤯 Our challenge
Most of our developers might have less experience with software design, especially complex systems. The architecture such as `Onion architecture`, `Hexagonal Architecture` or `Clean Architecture` might be overkill for most of them who have less knowledge about design. But they all know well `MVC` pattern, which is actually native pattern used in a standard Symfony project.

## 😎 Bingo ! D-MVC Architecture
I came to the idea to design this mixed project structure, so that the developers with less experience can follow and understand the architecture as well.

`MVC` is most well-known architecture which is widely used in `ruby on rails` and `Symfony framework`. 

But what is `D-MVC`? 😱
In fact, it is just based on the MVC principle, but inspired by common-used pattern `duck-redux` from Frontend-world. [read more on what is redux ducks?](https://medium.com/@matthew.holman/what-is-redux-ducks-46bcb1ad04b7)

> Ducks is a modular pattern that collocates actions, action types and reducers, which are used in redux implementation
Because the structure of the project looks like the ducks in the row, see the image below :D

![](https://stringydingding.com/wp-content/uploads/2020/01/20C99A3F-45ED-4A8F-9DB3-53CBA12C26C8-scaled.jpeg)

**the guideline in duck-MVC**: we built different **modules(i.e. ducks)** that are strictly designed and implemented in **`MVC`** pattern.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lfc07i58lvuk1jdw15vo.jpeg)


## 🚀 Every Developer knows well `MVC`
Because every developer knows well `MVC` and there is no need to coach them. We are able to get started easier and faster.
To make the project more familiar with standard Symfony project, I kept the `View` layer as default in `Symfony framework`, i.e. all views are still located in **`/templates`** folder.

Each `duck` should contain just the three parts:
- **Controller:** controller the web request or API request
- **Model:** all domain specific services, models, which are common used by the controller.
- **View:** in fact, they are located in `/templates` folder (This is standard way from Symfony framework. I kept the thing as simple as possible. Sure, it can be moved directly within a `duck :: user` folder, too.)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1p6zhhx34rzwo0tsu26t.png)

Based on this `D-MVC` approach, we are able to build different modules for the business domains. It can be very easily scaled with more modules.

- **Schedule:** module to manage the schedule of talks 
- **Security:** module to manage authentication and SSO
- **Tweet:** module to manage the conference tweets and ratings
- **User:** module to manage the users
- **... other modules**

## ✅ Getting things done
the cool part of this approach is the possibility to maximize the team velocity with less knowledge in software architecture. Additionally, I have still the following important things involved in this approach:

### Domain
I don't divide the domains into pieces and distribute them in the different `ducks`. Because most of them are shared among the different domains. Putting them together will reduce the cost of maintenance and the code can be shared friendly among the `ducks`.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4382ab9daax34s8l8yof.png)

The `domain` folder contains the most important domain related stuffs:
- `Entities`: the doctrine entities
- `Validations`: the implementations of the business rules
- `Value Objects`: the domain specific value objects

## 👥 Conclusion
This solution is a good approach for a team, which has less architecture knowledge. It can maximize the team effort without taking too much time in thinking it over, where should I put the files. The developer should just follow the basic principles, which they learned in the past `MVC` projects. It should work.

#### Additionally, we have still some valuable wins:

- **scalability**: Project can be scaled very easily. It will still keep the project in the very clear structure, if the project domains become complex.

- **simplicity**: there is `no magic` in this solution, but very **pragmatical**. Every developer can get started very easily with this setup and less design knowledge is required.

- **domain-driven**: because we try to build the small `ducks` for the special domains. It help both the business and development to track the problem as quick as possible in the target `duck` area.

- **Mobility**: Each `duck` has the standard `MVC` structure. The code can be transformed very easily into `micro-service`, if it is needed.

*This article might not be able to be used as a solution template, because there is still something that are not included and explained. But it can be an inspiration for finding a pragmatic solution for Symfony web development. If it will help u or if you have any question, feel free to write the comments or get the contact directly with me.*