Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I'm working on a project which is probably going to grow with time. So, I decided to break this into different projects running on different domains and different team will handle different sub-project. I thought it would be less headache to the teams if they do not have to keep concern about the other part of the main project(say, b2b project is not concern to the b2c project). Well, I thought that way. But, the problem is the whole project(b2b + b2c + apis + ..) is running on same database. Was that a bad decision, as some things look troublesome? I'm not that good architect(as a matter of fact, just a junior programmer). Any kind of discussion or tips would be great help to me.
I'd say it depends on how closely the two projects are related and cross paths... You could use two databases and communicate through APIs and make use of Laravel's Passport and Socalite if necessary. Alternatively, you could configure both databases in both applications and have them connect to each other as needed. Again though, it all depends on how much overlap there is.
Without more information, it's hard to really advise you on the best course of action.
You could keep the database on a separate server and both projects could access it through an internal api.
The overlap is quite large. There are about 80 tables. Administration ERP project uses all of them, B2B is using likely 50, B2C using about 50, API's for web app and mobile app are also using some of them. And there will be other projects(like: data analysis, modeling and simulation etc..) to be done on same database. The main problem is about duplication of codes. The projects are using same models/relational functions/helper classes/constants. So, whenever a business logic changes, I should change all of them. That’s what disturbing me. I have thought about keeping the database external and communicate with it via some API layer around it, and all the other project will access the same API layer. But that project then going to be a huge one. That's also frightening me.
@ShafiqulIslam Yes, your api will be a large project, but all your database logic will be centralized so you will have less code duplication. For other common code, you could pull it out into composer packages so that if something changes, you can simply update the packages rather than spending half a day hunting down code.
@shafiqulislam @zachleigh I am having a similar kind of problem with my project. The project is divided into many sub-projects. I am having some problems understanding what you guys are discussing. Communication via API means I will have to develop an API and rather than using eloquent methods. Is it !?
Please or to participate in this conversation.