Some frequently asked questions.
No, not really. When exploring new terrain it’s hard to do all the thinking beforehand. Usually you don’t even know where to draw the bounded contexts in your app from the start. Only after a while it becomes more evident what stays. Martin Fowler writes more about it in MonolithFirst
No rails isn’t bad, rails is awesome. It allows you to go fast and deliver at breakneck speed. And probably if you have these problems you’re already pretty successful. This is just a guide when you got to a point when you want to break up your monolith into a modular monolith. Or make you aware that there are different patterns that you can employ to prevent this.
- Hard to replace parts of the application.
- Hard to test parts in isolation.
- Lot of cognetive strain since the code touches big parts of the codebase.
I put the engines in the same folder as the rest of the rails repo. Directly in the root folder. Decidem has a good example on how to do this. Some people put them in an
engines/ folder like Flexport.
You can use rubocop to make sure engineers don’t accidently cross the boundaries. Flexport has build a gem for this to keep the boundaries in check.
Monorepo, its much easier to make changes across the app if you need to.
Just deploy like you always do! Its the same rails application.
You just test your engine in isolation. And the depending engines that might break. Dan Manges has a pretty good article about it on how to test only the affected engines.
You can assign dedicated teams dedicated bounded contexts or engines.