Visual Studio、Git、および一般的なコード
Gitで（GitLabを使用して）より簡単に管理し、Visual Studioで開発できるように、現在取り組んでいる大規模な新しいプロジェクトをどのように配置すべきかについてのアドバイスを探しています。
規模の概念を示すために、これはサーバーバックエンド全体であり、いくつかのネットワーキングサービス（ソケット）、データ処理サービス、およびWebサービスで構成されます。これらの各サービスは個別のプロジェクトになりますが、分離して、それらの間で共有したい多くの一般的なコードが含まれることになります（つまり、共有アセンブリ）。
したがって、次のVisual Studioプロジェクトがあり、依存関係が示されているとします。
Utility
SharedSocketCode - [ Utility ]
SocketServiceA - [ SharedSocketCode ]
SocketServiceA.WindowsServiceHost - [ SocketServiceA ]
SocketServiceA.ConsoleHost - [ SocketServiceA ]
SocketServiceB - [ SharedSocketCode ]
SocketServiceB.WindowsServiceHost - [ SocketServiceB ]
SocketServiceB.ConsoleHost - [ SocketServiceB ]
DbEntityModel
DataLogServiceA - [ DbEntityModel, Utility ]
DataLogServiceB - [ DbEntityModel ]
SharedWebServiceCode
WebServiceA - [ SharedWebServiceCode, DbEntityModel ]
WebServiceB - [ SharedWebServiceCode, DbEntityModel ]
ご覧のとおり、多くの共有コードがあり、これは氷山の一角にすぎません！これらすべてを同じリポジトリーに保管するか、それらを個別のリポジトリーに分割しようとしているのか、悩んでいます。
前者は、各ユーザーのローカルバージョンの異なる場所にある可能性のある場所で共有コードを探すVisual Studioと格闘する必要がないため、保守が簡単に思えます。プロジェクトはすべてソリューションレベルで予測どおりに保存されます。
後者の方が、各コンポーネントのバージョン管理と、そうでなければ1つの巨大なコードベースになるものを論理的に分離することをより詳細に制御できるように思えます。
私はGitとGitLabに非常に慣れていないので、この種のシナリオに役立つものがあるかどうかはわかりません。どんなアドバイスでも大歓迎です。
（参考までに、GitHubタグを追加したのは、GitLabにかなり似ているため、ユーザーからの支援が得られる可能性があるためです）
あなたと@antlersoftがコメントで述べたように、Visual Studio Solutionをライブラリを作成するいくつかのProjectsに分割することで、すばらしい成果を上げていると思います。
このようにして、これらのライブラリを参照するスタンドアロンのバイナリ（コマンドラインexeなど）を作成する他のいくつかのSolutionsまたはプロジェクトを作成できます（ソリューションエクスプローラー：参照を追加）。
GitまたはVisual Studioが（1つまたは複数のソリューションのソフトウェアアーキテクトとして）行っていないことの1つは、modulesの間で参照を相互にほどくことです（ここではライブラリの同義語を使用しています）。
より大きなすべてのソフトウェアシステムにレイヤードアーキテクチャを持たせることをお勧めします。システム全体を再構築してシステム全体を再構築するときは、次のベストプラクティスに従うことができます。
- このライブラリのすべてのソースファイルに広がる各ライブラリの名前空間を作成する
- 使用方法を確認します。この.csファイル（およびその名前空間と、個別のプロジェクトとしてコンパイルされるライブラリ）は、このライブラリのクラスを使用します
- すべての名前空間/ライブラリを1つのレイヤーに割り当てます（レイヤーに名前を付ける必要はありません）。これを紙で行うか、コンポーネント図をサポートする任意のUMLツール（より高い評価のVisual Studioバージョンのツールを含む。一部のUMLツールは明示的にレイヤー図と呼びます）を使用できます。
結局のところ、特定のレイヤーのライブラリーが上のレイヤー（上向き矢印なし）または同じレイヤー（横向き矢印）のライブラリーを使用していない場合、優れたアーキテクチャーが実現します。これを簡単に行うことができない場合は、同じレイヤーへのアクセスを許可する、より弱い形式を使用できます。
{プレビューバージョンのVisual Studio "15"（これは究極のVSですが、まだ利用可能な場合）をダウンロードすると、プロジェクトを開いてArchitectureメニューからNew Diagramを選択できます（ [ツール]のすぐ隣にあるLayer Diagramを選択して、少し遊んでみてください。最初の図を作成した後に、ハウツービデオがリンクされています。次のスクリーンショットは、ソリューションエクスプローラーからライブラリの一部をドラッグして右クリックし、[依存関係の生成]を選択すると表示される生成された図を示しています。 }
次のリファクタリングは、そこに到達するのに役立ちます。
- クラス全体を別の名前空間/ライブラリに移動する
- プロパティ/フィールドを継承階層の上または下に移動して、このプロパティ/フィールドへのアクセスから発生する依存関係を別の名前空間に移動します
- 同じ理由でメソッドを継承階層の上または下に移動する
- a）プロパティ/フィールドおよび/またはメソッドのサブセットのみを含むより一般的なスーパークラスを追加するか、b）より具体的なサブクラスを作成することにより、追加の分類を行います。
re-architecturingまたはrefactoringを実行して、ライブラリ間の（package/namespace/module）依存関係を解決して、既存のソフトウェアを追加のプロジェクトで再利用することにより、非常に大量の出版物が作成されました。私はそれをuntanglingと呼びましたが、実際には科学的な用語ではありません。これをカバーする優れた本のリファレンスの1つ（およびgitの時代の前に書かれたが、それでも非常に優れたソースです）は Gang-of-Four Book で、用語を使用していますdesign（オブジェクト指向の分析および設計と同様）。 re-architecturingまたは単にarchitectureまたはrefactoringを使用して、いくつかの非常に優れた本または記事を見つけることもできますお気に入りの書店や検索エンジンで。
もう一度再確認します。プロジェクトラインをこのように再調整すると、各プロジェクトはgitリポジトリとしても使用できる候補となり、このライブラリを再利用したい他のソリューションにチェックアウトできます。