🗣 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

🤯 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?

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

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

🚀 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.)

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.

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.