The new test class will look like:Nested of seeding the data globally in the base test class setup, we use the seed helper function to run the “MaritalStatusesSeeder” while it’s a part of the user module, and we use custom migrate helper to migrate only the tables related to the current test, in our case the user related tables.As you can see in DATABASE_MIGRATIONS_USER, we restructure the database migrations folder and group each set of migrations as folder per module.Almost every test case in a suite of ~1k test cases failed, just because not all tables –even from unexpected modules- exist..We try to investigate where these couplings live, and we are amazed that we have coupled Tests, Controllers, Models, Form Requests, Middleware, API Resources, Jobs, And even Migrations files!Absolutely, it is not the Framework problem, nor a Monolithic app requirement to couple your app like this, but let us face the fact, you cannot develop a big project without end with these problems, and we need a way to force that decoupling..Remove the usage of full Database Migration is the first step in this journey.The most confusing yet simple coupling is the migrations, how migrate a table can cause coupling between modules in the first place?Oh, my foreign!.We cannot migrate the event module unless we migrate user module first, and this is not the case in Microservices world..Therefore, we decide to disable any cross modules foreign keys..You can do that using two approaches:Remove the foreign keys entirely and think about modules tables as they deploy in different databases like a real Microservices.Keep them and use “enable/disableForeignKeyConstraints” helpers from Laravel Schema façade.In the next articles, we will dive deep into other types of coupling, and how can Laravel help us deal with some of them..We also developed some custom solutions to solve more complicated problems, and we will share them as snippets or open source packages with each article.Stay tuned!. More details