クライアント/サーバーアプリケーションのタマネギアーキテクチャ
新しいプロジェクト、クロスプラットフォームを見つめています。そこでオニオンアーキテクチャを使いたいです。教育目的のためだけのシンプルなゲーム（三目並べ）になります。このアプリはクライアントサーバー型になります。
今、私はタマネギのアーキテクチャーについてたくさん読んでいますが、クライアント/サーバーでそれをどのように処理するかまだ正確にはわかりません。
サーバー用とクライアント用に2つの異なるリポジトリ（1）を作成する必要がありますか？または、両方を単一のソリューションで保持する必要があります（2）（コア/ドメインの多くのクラス/インターフェースが両方で同じであるため） ？
- （1）-ソースコードリポジトリ（bitbucketまたはsthなど）
- （2）-Visual Studioソリューション
編集：
これもクロスプラットフォームアプリ（xamarinを介したC＃）であり、C＃にも単一サーバーが含まれます。 WCF経由の通信。サーバーはユーザーアカウントを保存し、すべての動きを監視し、ゲームの履歴を保存します-重要ではありません。
@Kasperに答えて、クライアント/サーバーアプリでOAを確認するにはどうすればよいですか。
エンティティ、ヘルパー、ロガー（？）、インターフェースなどのオニオンのCoreで可能な限り多くのコードを共有できると思ったので、別のレイヤーを作成します-Client APIのプロジェクト（アプリケーションおよびドメインサービス）およびServer API（アプリケーションサービス-クライアントとの間のメッセージの消費と送信）、次にInterfaceレイヤー。クライアント用とサーバー用に分かれています。
したがって、単一のVSソリューション、2つのアプリ、単一のCore。私はそれが技術的に可能であることを知っています-しかし、それは良い習慣ですか？
「リポジトリ」が何を意味するのかは明確ではありません。 ソースコードリポジトリですか？この場合、必ず1つのリポジトリのみを使用してください。
また、「解決策」が何を意味するのか明確ではありません。 C＃を使用しているため、おそらくVisual Studioであり、Visual Studioでは「ソリューション」はすべてのプロジェクトのコンテナーです。したがって、必ず1つのソリューションを使用してください。このソリューションには複数のプロジェクトが含まれます。
したがって、「Tic Tac Toe」ソリューションには以下が含まれます。
- クライアント用の1つの「クライアント」プロジェクト（おそらくタイプWinFormsアプリケーション？）
- サーバー用の1つの「サーバー」プロジェクト（おそらくタイプコンソールアプリケーション？）
- 両方に共通のすべてのコードを含む1つの「TicTacToe」プロジェクト（タイプクラスライブラリの）。
「クライアント」プロジェクトは「TicTacToe」プロジェクトに依存（利用）し、「サーバー」プロジェクトも「TicTacToe」プロジェクトに依存（利用）します。
さらに、クライアントプロジェクトがサーバープロジェクトを直接呼び出さない（ソースコードレベルでは使用できない）場合でも、サーバーに依存するものとしてクライアントを定義する必要があります。クライアントを実行するたびに、 Visual Studioでサーバーが最新であることを確認する必要があります。 （コンパイルされました。）次に、サーバーが再コンパイルされるたびにサーバーを自動的に再起動するメカニズムを用意することもできますが、それはこの質問の範囲を超えています。
したがって、TicTacToeクラスライブラリプロジェクトはタマネギの中心と考えることができ、サーバーアプリケーションプロジェクトはタマネギの中間層と考えることができ、クライアントアプリケーションプロジェクトはタマネギの外側層と考えることができます。 。