Looking at the effort invested into migrating encounter diagnoses and conditions from the emrapi module into core, i sit back and reflect asking myself, “Is it worth it?” This code had reached a level of stability while running from the emrapi module. Now that we have moved it, have to deprecate it in the module, migrate existing data into new tables/format, there is a likelihood of introducing some kind of instability, despite our best to avoid it. And in all this, there seems to be no value added from the end user’s perspective. If we continue with this approach, i would see the core expanding to such a huge monolith in years to come with features or functionality that not every implementation requires, and have no way of taking it out if they do not use it.
One of the greatest challenges that i have seen implementations face is upgrading of the core platform. These same implementations are most of the times using the latest releases of the various modules. Confirming how easier it is to deal with functionality separated out as modules.
The cohort builder bug has given us some bit of headache because the fix in core would not be easily available to implementations which may not be ready to upgrade. If this feature was in some sort of module, it would be a different story.
We all know how easy it is to fix bugs or add new features in modules and release almost immediately without the hassle of cases that deal with core.
Am starting to think that our strategy should change from moving services or groups of functionality into core. But instead, have them as modules to reduce the coupling and have more flexible and faster release cycles. Though this is not building micro services in their true sense, but the tendency is in the same direction to address some of the driving forces towards a micro services based architecture.
Of course there are pros and cons for each approach. It could be that am excited and just need to hear it from another angle, to get it. 
