システム/アプリ間でレポートモジュールを共有するのは良い習慣ですか、悪い習慣ですか？
私の新しい仕事では、システム/アプリ間でモジュールを共有したいという人が何人かいますが、私はそれについて少し懐疑的です。
コンテキスト：さまざまなサーバーに小さなアプリがたくさんあります。それらのいくつかはスクレーパーであり、いくつかは単なるWebアプリなどです...それらも異なる言語（Java、javascript、php、python）である可能性がありますそれらに共通しているのは、さまざまなクライアントのcsv/xlsxへのエクスポートです。
したがって、アイデアは、すべてのシステム/アプリが使用できる共有「エクスポートモジュール」を作成することでした。
新しいワークフローは、彼らが作成したいものです：
- データをスクレイプ/処理する
- この情報をデータベースに保存します（私には意味があります）
- 次に、独自のモジュールを使用して、現在すべてのアプリが独自に作成している「出力」を作成します。
最後の部分は私が安全でない部分です。一意の（おそらくnodeJS）モジュールが、異なるビジネスロジックを持つ異なるシステムに対して正しい出力を取得しようとする部分です。たとえば、一部のスクレーパーは、名前に週の最後の月曜日を含むファイルを作成します。 、別の1つは、名前に「today」を含むcsvファイルを作成するだけです。
その時点でモジュールを共有することは可能ですか、またはすべてのアプリが独立していてアトミックであるほうが良いですか
概要：2つのオプション
1）異なる言語の複数のシステムがデータをデータベースに保存し、一意のモジュールがそれらからの出力を作成します
2）csvやExcelなどにエクスポートする「独自の」ライブラリを備えたすべてのシステム...必要に応じて（まだデータベースにデータを保存しています）
考慮すべき原則の1つは、複数の言語で書く場合は、複数の言語をサポートできるチームを見つける必要があるということです。最大の懸念ではありませんが、言及する価値があります。小さなマイクロサービスにgolangを使用したい場所で働いていましたが、Javaを使用することにしました。Javaスタッフの専門家とそのポジションの埋め戻しを見つけるのは簡単です。
私が最初に尋ねる質問は、「ここでどんな問題が解決されているのですか？」です。彼らがやりたいのは、1つのエクスポートモジュールを用意して、コードをDRY（繰り返さないでください））できるようにすることです。これは良いことです。保守性に役立ちます。しかし、ここで最大の問題は何ですか？それは保守性ですか？
さらに、顧客に提供する必要のあるデータ構造はどのように異なりますか？顧客はどのようにしてデータにアクセスしていますか（同じ方法で、または異なる方法で）？これらはまた、あなたに決定を示すかもしれないと思います。
マイクロサービスは、ここで検討するのに適したパラダイムかもしれません。すべてのアプリは独自のサービスである可能性があり、「ETL」マイクロサービスはデータを異なるデータベーステーブルにロードする可能性があります。さまざまなWebエンドポイントがさまざまなテーブルにアクセスできます。
最終的には、決定を下す前に問題の説明を検討する必要があると思いますが、どちらのアプローチも役立つ可能性があります。