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
Most of our developers might have less experience with software design, especially complex systems. The architecture such as
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.
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
But what is
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
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
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
/templatesfolder (This is standard way from Symfony framework. I kept the thing as simple as possible. Sure, it can be moved directly within a
duck :: userfolder, 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
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:
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
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
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.
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 magicin 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
ducksfor the special domains. It help both the business and development to track the problem as quick as possible in the target
duckhas the standard
MVCstructure. 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.