私はより簡単な方法を見つけるためにいつも考えている問題があります。 ここにシナリオがあります（これは単なる例です）。複数のプロジェクト間で共通のパッケージを使用するベストプラクティス
ロギングとロギングが必要なシステムがシステム全体で同じパターンを持つとします。したがって、それを別のプロジェクトに実装し、それをあるバージョンのパッケージとして公開するのが最善の方法です。必要なすべてのプロジェクトで参照してください。私の懸案事項/問題は、このロギングパッケージを更新すると、それらのパッケージをすべて調べて、ロギングパッケージのバージョンを更新する（またはプロジェクトを実行してパッケージを更新するスクリプトを書く）必要があるということです。これは、巨大なシステムでは時間がかかることがあります。
ベストプラクティスは何ですか？
私は、インターフェイスと実装の2つの部分を持っています。それはあなたのコードがインターフェイス内でプルするだけで、依存関係管理（nuget、gradleなど）を使って実装を更新することは自由です。インタフェースが変更された場合にのみ、コードを更新する必要があります。
良い例では、インターフェイスを提供しますlog4jのである、と実装を提供する多くのライブラリがあります。logback SLF4Jなどが...
ありがとうございます@リチャード、私は実装を共有したい場合はあなたが正しいですが、私の主な関心事は共通のパッケージを持っています。ロギングは単なる例でした。それはプロジェクト間で共通のシステムのどの部分であってもかまいません。 log4netの代わりにserilogで更新すると、このロギングケースを想像してみてください。これらのプロジェクトをすべてこの新しいバージョンに更新する必要があります。そして、これはシステム全体で巨大な更新となることが分かります。私は別の方法でこれを解決できるかどうか疑問に思った:) – ShrnPrmshr
あなたは本当にそれを手作業で行う必要があります。そうしないと、コンポーネントを担当するチームが変更の可視性を持たないため、非常に不安定なシステムになります。それらの依存関係は新しいバージョンでテストする必要があることを認識しません。ロギング実装のインスタンスを1つだけにしたい場合は、syslogのようなロギングサービスを起動します。プリンシパルは同じです。契約と実装（またはサービス）を分けて、できるだけ契約を変更しないようにしてください。 –
良い質問、しかし、言語に関するご質問、お使いのタイトルやタグを向上させてください、といくつかのコード例を示します（必要な場合）。 –
素晴らしいアイデア、私は質問を更新しました。うまくいけばそれはより理解できる。 – ShrnPrmshr