如何正确编写具有共享功能的功能驱动的体系结构？
我正在将我的整体建筑应用程序重写为Vue.js的功能驱动的建筑。由于我们正在向组织雇用更多的人，因此我们需要能够将工人分配到不同的功能/领域。
我们创建了功能目录，其中具有不同的域端点作为功能。例如，“功能/药物/主动验证”。在那里，我们拥有对物质的管理；添加，创建，编辑，显示所有相关品牌等。
现在，我们的第二个功能是“功能/血液学”。我们管理那里的患者，相关文件等。但是我们需要使用活性物质，例如过滤和创建患者治疗计划。当我们需要使用活性物质时，我们的问题现在就会出现。血液学功能不应使用“功能/药物/活跃剂”中的服务。如果我确实使用并编辑了来自Active物质功能的一些服务或组件，那么它很可能会为该团队打破一些东西。这只是其中一个示例，但是有许多类似的模块需要在某种程度上进行交流。
那么，我的问题是如何解决这个问题？我是否再次将整个逻辑再次重写为摧毁干净体系结构的血液学功能，还是从导致高耦合的活动物质功能中导入所需的服务？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于管道上没有很多上下文，或者您是否做TDD以及如何处理依赖项。
肯定有整体应用程序的缺点和上行。
根据我的经验，现在使用Vitejs，胖水疗中心并不是一个大问题。
也许不是解决您的答案的方法，但是对环境的增强可以改善代码隔离和任务组织。
我们构建项目的方式是，我们拥有一个根项目，该项目可以容纳VITE配置并自动加载其他功能，我们将其分为其他GIT存储库，然后我们再次将其作为NPM软件包部署到我们公司的内部NPM注册表。对于私人项目，我使用私人NPM软件包。
有此功能：
library模式在Vite Eco System上。
然后，您可以在root项目中导入拆分项目的出口：
从'@org/功能'导入{x，y}。
包括路由器在Eco系统中的懒惰加载功能，它确实变得快速且易于管理，具有井井有条并有效地性能的前端单片。
有了一些基本的经验，您还可以动态地选择要加载和导入和注入哪些库或安装它们以VUE 3 ECO系统。取决于您大量使用的功能。
因此，也许在完全抛弃整体化之前，然后前往微观前端，以应对每个开发人员环境中的cookie，cors，域，域，问题。考虑这些见解，保证并进行。
如果选择上面建议的选项，则最初决定命名空间模式，唯一。
在由功能软件包导出的路由器模块上应用模式。
在由功能软件包导出的商店模块上应用图案。
命名空间节省了一些时间并提供锚点点，您可以通过不同的软件包引起的问题来调试问题，并根据他们可以访问ex的命名空间来隔离用户访问：state：user..access [“ dashboard_read”，“ tasks_write”]，然后您还可以为您的VUE路由器创建中间件，以执行检查用户是否可以在非常基本的情况下到达，或者使用CASL通过后续会话等通过迭代访问权限来授予对用户的访问。
这些实践也可以测试单位和E2E。我们在企业等级积极使用它们。没有速度，性能或组织的问题。每个功能或一组功能都有/拥有自己的回购，他们的问题与各自的作者相吻合，并且他们有自己的测试可以通过。
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.