I am running an ecommerce website built in Java using Spring and Hibernate. If I have to briefly describe current architecture then it is like this:
- I am having two projects by name – store front and admin
- Storefront project holds DAO, model, service, controller and views for showing the storefront view of website and also hold APIs for apps. In a gross level perfect MVC architecture.
- Admin project holds DAO, model, service, controller and views for showing the backend/admin interfaces for managing this ecommerce store. It is also a perfect MVC architecture.
-
Storefront and admin both can be build and deployed independently.
-
Storefront makes heavy use of cache, by pulling out most of catalog data into the memory.
- Both projects independently talk with same MySQL database for all CRUD operations.
- Whenever any communication is required between these two projects, they do that using REST APIs.
- I Followed this architecture to develop both projects independently, keep them light, and deploy them independently.
Everything is running fine, but many times I get a feeling that it may not be the correct approach to solve my problem. Problems that I frequently face are:
- It causes code duplicacy, mostly in Models, as it is something both projects have but most properties in them are common.
-
Along with models, code duplicacy happens in service and DAO as well, it is not that much but we can assume atleast 30% is duplicate in them as well.
-
If any changes is required in database, then I have to make sure those changes are properly made in both projects as both are making independent DB calls.
Please suggest what could be the best approach for handling and architecting such project.
This project and website is not quite small as well. If I have to give you some idea then following are stats:
- Around 1 million products
- Monthly traffic around 1 million
- Per day orders around 1000
- Both projects constitute around 1000 class files and more than 300 JSPs
- We are a team of just 3 full stack developers.
What could be the best approach by which we can manage this project with minimum code duplicacy, easy to build and share between team members. And project that could scale as well keeping future growth in mind.
Best Answer
Code duplication is definitely a tell that you have some re-usable components that haven't been factored out yet.
It sounds to me like you have a situation something like the following at present:
If you're seeing a lot of duplicated code, you might try something more like the following:
You can then build a web service client (say, with Feign https://github.com/OpenFeign/feign or the like) and pull the contract objects into that JAR file. That way both systems communicate with the same REST service for their information and reuse the DTOs that represent the contract. Database changes would only require changes in the service, though contract changes may require changes in both apps.