How to correctly write feature driven architecture with shared features?

Question

I am rewriting my monolithic architectural application into feature driven architecture in Vue.js. Since we are hiring more people to our organization, we need to be able to assign workers into different features/domains to work with.

We have created features directory where we have different domain endpoints as features. For example, “feature/medicines/active-substances”. In there we have the management of the substances; adding, creating, editing, displaying all relating brands etc.

Now our second feature is “features/hematology”. We manage patients there, related documents etc. But we need to use active substances for example filtering and creating patient treatment plans. Our problem comes now when we need to use active substances. Hematology feature should not use the services from “features/medicines/active-substances”. If I did use and edit some of the services or components from active substances feature, then it would most likely break something for that team. This is just one of the examples but there are many modules like this which need to communicate at some level.

So, my question is how to solve this problem? Do I rewrite the whole logic again into the hematology feature again which destroys clean architecture, or do I import the needed services from the active substances feature which leads to high coupling?

Answer 1

Since there is not a lot context on your pipelines or if you do TDD and how you handle your dependencies.

There's the downside and the upside of the monolithic apps for sure.

On my experience and now with Vitejs a fat SPA is not a big problem when it comes to have it or not a monolithic.

Maybe not a solution to your answer but an enhancement to your environment would improve code isolation and task organizaton.

The way we structure the projects is that we have a root project which houses vite configuration and autoloading other features we split to other git repositories which we then again deploy as npm packages to an internal NPM Registry at our company. For private projects I use private npm packages.

There is this feature: Library mode at Vite eco system and it bundles your split project as an npm ready. Then you can import exports of your split project at your root project as: import { x, y } from '@org/features'.

Including the lazy loading features of the router in the eco system it really becomes blazing fast and manageable to have frontend monolithics which are well organized and perform efficiently.

With some basic experience you can dynamically also chose which libraries to load and import and inject or install them to Vue 3 eco system. Depending which features you heavily use.

So maybe, before ditching monolithic entirely and heading to Micro Frontends to deal with cookie, CORS, Domain, issues on every developer environment. Consider these insights, reasses and proceed.

If you choose the option suggested above, initially decide a NAMESPACE pattern, unique.

• Apply use of the pattern on router modules exported by feature packages.

• Apply use of the pattern on store modules exported by feature packages.

• Namespaces save you some time and provide anchor points which you can debug issues arising from different packages and isolate user access based on namespaces they have access to e.x: state: user.access["DASHBOARD_READ", "TASKS_WRITE"] then you can create also a middleware to your vue router to perform checks if user can reach or not them at the very basic or use casl to grant access to user by iterating their access by backend to their session etc.

Also these practices are testable both unit and e2e. We use them actively at enterprise grade. No issues with speed, performance or organizaton. Each feature or group of features has/have its own repo their issues meet their respective authors and they have their own tests to pass.