プロジェクトの構成

Lino は、スケーラブルでモジュール化されたプロジェクトを効率的に作成するために開発されました。層間での責任の明確な分離を備えた、よく構成されたソリューションを提供し、プロジェクトのニーズの進化に応じて成長できる準備が整っています。


Lino を使用してプロジェクトを作成すると、パフォーマンス、スケーラビリティ、およびメンテナンスの容易さに重点を置いた、アーキテクチャとモジュール化のベストプラクティスに従った.NETソリューションが生成されます。

新しいプロジェクトの作成

コマンド lino project は、新しい .NET プロジェクトの作成をシンプルかつ効率的に行うためのツールです。このコマンドを使用すると、プロジェクトの構造を設定し、必要な依存関係を選択し、言語やインフラの設定を行うことができます。

新しいプロジェクトを作成するには、次のコマンドを使用します：

lino project new

実行中に、CLI は次の情報を求めます：

  • プロジェクトの名前空間： ソリューションの主要な名前空間を定義します。
  • 表示名： インターフェースに表示されるフレンドリーネームです。
  • プログラミング言語： 現在、C# (.NET) のみがサポートされています。
  • 開発スタック： 現在、.NET 9 と Aspire がサポートされています。
  • コード解析ツールを使用しますか？ 「はい」か「いいえ」を選択してください。
  • 分散キャッシュを使用しますか？ 「はい」か「いいえ」を選択してください。
  • 非同期通信を使用しますか？ 「はい」か「いいえ」を選択してください。
  • データの言語： システム内で使用されるエンティティ名やその他のデータの言語を定義します。
  • アプリケーションでサポートされている言語： 最大10言語までの国際化（i18n）をサポートします。
  • デフォルト言語： API、レスポンスメッセージ、バリデーション、ユーザーインターフェースで使用される主要な言語を定義します。

情報を確認した後、Lino は自動的にプロジェクトの構造を作成します。以下のようになります： 

MyApp/
├── MyApp.sln
├── src/
│   ├── Aspire/
│   │   ├── AppHost/
│   │   │   └── MyApp.AppHost.csproj
│   │   └── ServiceDefaults/
│   │       └── MyApp.ServiceDefaults.csproj
│   └── Services/
│       └── Shared/
│           ├── API/
│           │   └── MyApp.Shared.API.csproj
│           ├── Application/
│           │   └── MyApp.Shared.Application.csproj
│           ├── Domain/
│           │   └── MyApp.Shared.Domain.csproj
│           ├── Infrastructure/
│           │   └── MyApp.Shared.Infrastructure.csproj
│           └── Infrastructure.Persistence/
│               └── MyApp.Shared.Infrastructure.Persistence.csproj
└── tests/

コード解析ツール

静的コード解析ツールは、開発中にコードの品質と一貫性を確保するための強力なツールです。これらは実行することなくソースコードを検査し、エラーやスタイルの問題、その他の不整合を検出します。

プロジェクト作成時にコード解析ツールを有効にすることを選択した場合、CLI は自動的に次のパッケージを設定します：

  • StyleCop.Analyzers： コードのスタイルをチェックし、インデント、スペース、命名規則などを検証します。
  • SonarAnalyzer.CSharp： コード品質とセキュリティのためのルールセットで、一般的なバグや潜在的な脆弱性を検出します。
  • Roslynator.Analyzers： C# コードに対する多くの品質向上ルールを提供し、リファクタリングや最適化の機会を特定します。

コード解析ツールの利点：

  • 品質向上： コードをクリーンで読みやすく、一般的な問題がないように保ちます。
  • エラー予防： 実行前にエラーを検出し、開発者が早期に問題を修正できるようにします。
  • 標準化： 全ての開発者が同じスタイル規則を守ることを保証し、コードの一貫性を向上させます。
  • 支援付きリファクタリング： コードのリファクタリングをサポートし、改善の提案を提供します。

コード解析ツールを有効にすることで、コードの品質を積極的に向上させ、プロダクション環境での障害リスクを減らすことができます。

分散キャッシュ

分散キャッシュは、アプリケーションのパフォーマンスとスケーラビリティを向上させるための技術で、頻繁にアクセスされるデータをデータベース外のキャッシュ層に保存します。これにより、アプリケーションのインスタンスが効率的にキャッシュデータを共有し、高い可用性と応答時間の短縮が実現します。

プロジェクト作成時に分散キャッシュを有効にすると、Redis が Aspire コンテナに統合され、高可用性のキャッシュシステムが提供されます。

分散キャッシュの利点：

  • パフォーマンス向上： リクエストの応答時間を短縮し、データベースアクセスを最小限に抑えます。
  • スケーラビリティ： 分散キャッシュにより、アプリケーションは水平スケーリングが可能になり、複数のインスタンスから透明にアクセスできます。
  • 高可用性： Redis を使用することで、障害が発生してもキャッシュは利用可能で、分散システムに強力なソリューションを提供します。
  • コスト削減： データベースやシステムの負荷を減らし、繰り返しリクエストの処理負担を軽減します。

分散キャッシュを有効にすると、アプリケーションのパフォーマンスが大幅に向上し、ユーザーに対する応答が迅速になり、バックエンドシステムの負荷が軽減されます。

非同期通信

非同期通信は、システムやコンポーネントがブロッキングなしで通信できるアプローチです。これにより、データの送受信が他のタスクの処理を妨げることなく行えます。特に分散システムや高負荷時の効率性と回復力が重要な場面で有用です。

非同期通信を有効にすることを選択すると、RabbitMQ がプロジェクトに統合され、MassTransit が設定されて非同期通信の使用を簡素化します。

非同期通信の利点：

  • パフォーマンス向上： システムの実行フローをブロックすることなく、操作を並列に実行できます。
  • スケーラビリティ： システムのスケーラビリティを向上させ、同時に大規模なデータやユーザーを処理できるようになります。
  • 回復力： 一時的な障害が発生しても、非同期通信によりメッセージを再処理したり後で処理することができます。
  • 疎結合： システムが直接的な即時応答に依存せずに通信できるように設計され、柔軟性と整理の向上を促進します。

RabbitMQ との統合と MassTransit の使用により、コンポーネント間の通信が効率的かつ回復力があり、アプリケーションのスケーラビリティと柔軟性が保証されます。

次のステップ

Lino で .NET プロジェクトを作成したら、お気に入りのコードエディタで開きます。Visual Studio、Visual Studio Code、または他の任意の IDE を使用できます。

プロジェクトを開いたら、アプリケーションを構成するサービスを追加して設定を開始できます。これが開発フローの次のステップです。

次のセクションでは、新しいプロジェクト内でサービスを作成および構成する方法を示し、アプリケーションのニーズに合わせて整理されたスケーラブルな成長に向けて準備を進めます。

サービスの作成と管理

プロジェクトを作成した後、次のステップはサービスを追加することです。Linoは、モノリシックシステムまたはマイクロサービスアーキテクチャで使用できるサービスを、シンプルで直感的な方法で作成する方法を提供します。

新しいサービスを作成するには、次のコマンドを使用してください：

lino service new

実行中に、CLIは次の情報を要求します：

  • サービスの名前空間： サービスの名前と名前空間を定義します。
  • 表示名： インターフェースに表示される親しみやすい名前です。
  • サービスの種類： 単純型またはモジュラー型を選択します。
  • データベース： PostgreSQLまたはSQL Serverを選択します。

サービスの種類が単純型の場合、次の追加情報も求められます：

  • アーキテクチャスタイル： 現在はClean Architectureのみがサポートされています。
  • Strongly Typed IDを使用しますか？ はいまたはいいえを選択します。

サービスの種類

単純型サービス： 単純型サービスは、より簡素な構造を持ち、モノリシックシステムや各サービスが独立した責任を持つマイクロサービスプロジェクトに適しています。

モジュラー型サービス： より大きなシステムには、より優れた組織化と拡張性が必要です。モジュラー型サービスを選択することができます。このタイプでは、サービスを小さく具体的なモジュールに分けることができ、システムのメンテナンスや拡張性が向上します。

単純型サービスでもモジュラー型サービスでも、データベースは各サービスに対して個別です。アーキテクチャとStrongly Typed IDの使用は単純型サービスに適用されます。モジュラー型サービスでは、この決定はサービス内で作成される各モジュールレベルで行われます。

Linoの構造は柔軟で、同じプロジェクト内で単純型とモジュラー型のサービスを作成することができます。

アーキテクチャスタイル

LinoはすべてのサービスにClean Architectureを適用しています。これにより、アプリケーションはしっかりとしたアーキテクチャに従い、責任の分離が促進され、メンテナンスと拡張性が向上します。

Clean Architectureの利点：

  • 分離： ビジネスロジックは技術的な詳細から独立しており、より大きな柔軟性とテスト可能性を提供します。
  • メンテナンス性： レイヤーが明確に分離されているため、システムの他の部分に影響を与えずに変更を加えることができます。
  • テスト可能性： 関心の分離により、各レイヤーに対してユニットテストや統合テストを独立して作成しやすくなります。
  • 拡張性： プロジェクトは簡単に拡張でき、コンポーネントはビジネスロジックに影響を与えることなく変更または交換できます。

単純型サービスを選択してClean Architecture実装を使用する場合、プロジェクトは次の構造で作成されます：

MyApp/
├── MyApp.sln
├── src/
│   ├── Aspire/
│   │   ├── AppHost/
│   │   │   └── MyApp.AppHost.csproj
│   │   └── ServiceDefaults/
│   │       └── MyApp.ServiceDefaults.csproj
│   ├── Integrations/
│   │   └── Internal/
│   │       └── MySimpleService/
│   │           └── Http/
│   │               ├── Clients/
│   │               │   └── MyApp.Integrations.MySimpleService.Http.Clients.csproj
│   │               └── Contracts/
│   │                   └── MyApp.Integrations.MySimpleService.Http.Contracts.csproj
│   └── Services/
│       ├── Shared/
│       │   ├── API/
│       │   │   └── MyApp.Shared.API.csproj
│       │   ├── Application/
│       │   │   └── MyApp.Shared.Application.csproj
│       │   ├── Domain/
│       │   │   └── MyApp.Shared.Domain.csproj
│       │   ├── Infrastructure/
│       │   │   └── MyApp.Shared.Infrastructure.csproj
│       │   └── Infrastructure.Persistence/
│       │       └── MyApp.Shared.Infrastructure.Persistence.csproj
│       └── MySimpleService/
│           ├── API/
│           │   └── MyApp.MySimpleService.API.csproj
│           ├── Application/
│           │   └── MyApp.MySimpleService.Application.csproj
│           ├── Domain/
│           │   └── MyApp.MySimpleService.Domain.csproj
│           ├── Infrastructure/
│           │   └── MyApp.MySimpleService.Infrastructure.csproj
│           ├── Infrastructure.Persistence/
│           │   └── MyApp.MySimpleService.Infrastructure.Persistence.csproj
│           └── IntegrationEvents/
│               └── MyApp.MySimpleService.IntegrationEvents.csproj
└── tests/
    └── Services/
        └── MySimpleService/
            ├── IntegrationTests/
            │   └── MyApp.MySimpleService.IntegrationTests.csproj
            └── UnitTests/
                └── MyApp.MySimpleService.UnitTests.csproj

モジュラー型サービスを選択すると、プロジェクトは次のような構造を採用し、開発中に新しいモジュールを柔軟かつ体系的に追加できます：

MyApp/
├── MyApp.sln
├── src/
│   ├── Aspire/
│   │   ├── AppHost/
│   │   │   └── MyApp.AppHost.csproj
│   │   └── ServiceDefaults/
│   │       └── MyApp.ServiceDefaults.csproj
│   └── Services/
│       ├── Shared/
│       │   ├── API/
│       │   │   └── MyApp.Shared.API.csproj
│       │   ├── Application/
│       │   │   └── MyApp.Shared.Application.csproj
│       │   ├── Domain/
│       │   │   └── MyApp.Shared.Domain.csproj
│       │   ├── Infrastructure/
│       │   │   └── MyApp.Shared.Infrastructure.csproj
│       │   └── Infrastructure.Persistence/
│       │       └── MyApp.Shared.Infrastructure.Persistence.csproj
│       └── MyModularService/
│           ├── Host/
│           │   └── MyApp.MyModularService.Host.csproj
│           ├── Infrastructure/
│           │   └── MyApp.MyModularService.Infrastructure.csproj
│           └── Modules/
└── tests/

Strongly Typed ID

Strongly Typed IDは、識別子（ID）の型をより具体的で強く型付けされたものにすることで、コードの安全性と明確性を向上させるアプローチです。これにより、intやguidなどの一般的な型を使用して一意のエンティティを表すことを避けることができます。

Strongly Typed IDを使用すると、例えばユーザーIDを表すために整数型のような一般的な型を使用するのではなく、ユーザーID専用の具体的な型を作成します。これにより、誤って異なる種類のIDを不適切なコンテキストで使用することを防ぐことができます。

Strongly Typed IDを使用する利点：

  • 型安全： IDが正しく使用されることを保証し、例えばユーザーIDと製品IDが混同されることを防ぎます。
  • 明確さ： 各IDの型が明確に表現され、コードがより理解しやすくなります。
  • リファクタリングの容易さ： 識別子の型を変更する必要がある場合、IDの型だけを変更すれば残りのコードは安全なままとなります。
  • エラーの回避： 識別子の型を誤って使うことによるバグの可能性が減ります。

モジュラーサービスの次のステップ

モジュラーサービスを作成した後、次のステップはモジュールを追加することです。モジュールはサービス内でビジネスロジックとインフラを独立して整理できるため、システムがよりスケーラブルで整理されたものになります。

次のセクションでは、モジュラーサービス内でモジュールを作成し管理する方法を説明します。これにより、モジュラーサービスの柔軟性と拡張性を最大限に活用することができます。

モジュールの作成と管理

モジュラーサービスを作成した後、次のステップはそのサービスにモジュールを追加することです。モジュールはビジネスロジックを独立して整理できるようにし、システムにさらにスケーラビリティと整理をもたらします。

新しいモジュールを作成するには、次のコマンドを使用してください：

lino module new

実行中に、CLIは次の情報を要求します：

  • サービス： 新しいモジュールが作成されるサービスを定義します。
  • モジュールの名前空間： モジュールの名前と名前空間を定義します。
  • 表示名： インターフェイスに表示されるフレンドリーネーム。
  • アーキテクチャスタイル： 現在はクリーンアーキテクチャのみ。
  • 強く型付けされたIDを使用しますか？ はいまたはいいえを選択します。

最後に、Linoはモジュールサービスの構造を保ちながら、新しいモジュールを生成します：

MyApp/
├── MyApp.sln
├── src/
│   ├── Aspire/
│   │   ├── AppHost/
│   │   │   └── MyApp.AppHost.csproj
│   │   └── ServiceDefaults/
│   │       └── MyApp.ServiceDefaults.csproj
│   ├── Integrations/
│   │   └── Internal/
│   │       └── MyModularService/
│   │           └── MyModule/
│   │               └── Http/
│   │                   ├── Clients/
│   │                   │   └── MyApp.Integrations.MyModularService.MyModule.Http.Clients.csproj
│   │                   └── Contracts/
│   │                       └── MyApp.Integrations.MyModularService.MyModule.Http.Contracts.csproj
│   └── Services/
│       ├── Shared/
│       │   ├── API/
│       │   │   └── MyApp.Shared.API.csproj
│       │   ├── Application/
│       │   │   └── MyApp.Shared.Application.csproj
│       │   ├── Domain/
│       │   │   └── MyApp.Shared.Domain.csproj
│       │   ├── Infrastructure/
│       │   │   └── MyApp.Shared.Infrastructure.csproj
│       │   └── Infrastructure.Persistence/
│       │       └── MyApp.Shared.Infrastructure.Persistence.csproj
│       └── MyModularService/
│           ├── Host/
│           │   └── MyApp.MyModularService.Host.csproj
│           ├── Infrastructure/
│           │   └── MyApp.MyModularService.Infrastructure.csproj
│           └── Modules/
│               └── MyModule/
│                   ├── API/
│                   │   └── MyApp.MyModularService.MyModule.API.csproj
│                   ├── Application/
│                   │   └── MyApp.MyModularService.MyModule.Application.csproj
│                   ├── Domain/
│                   │   └── MyApp.MyModularService.MyModule.Domain.csproj
│                   ├── Infrastructure/
│                   │   └── MyApp.MyModularService.MyModule.Infrastructure.csproj
│                   ├── Infrastructure.Persistence/
│                   │   └── MyApp.MyModularService.MyModule.Infrastructure.Persistence.csproj
│                   └── IntegrationEvents/
│                       └── MyApp.MyModularService.MyModule.IntegrationEvents.csproj
└── tests/
    └── Services/
        └── MyModularService/
            └── Modules/
                └── MyModule/
                    ├── IntegrationTests/
                    │   └── MyApp.MyModularService.MyModule.IntegrationTests.csproj
                    └── UnitTests/
                        └── MyApp.MyModularService.MyModule.UnitTests.csproj

データベースの構造

データベースはサービスに関連していることを強調することが重要です。モジュラーサービス内では、各モジュールは関連するデータベース内で自分のスキーマとして表現されます。このアプローチにより、複数の異なるデータベースを作成することなく、分離と整理が提供されます。

モジュール間の独立性について

サービス間に直接的な依存関係がないように、モジュールもサービス内で独立したプロジェクトとして作成されます。

この分離の利点：

  • 分離： 各モジュールは独立して進化でき、メンテナンスと継続的な進化が容易になります。
  • 整理： アプリケーションは真にモジュラー化され、境界（Bounded Context）を守り、ソフトウェアアーキテクチャのベストプラクティスを促進します。
  • 柔軟性： サービスの他のモジュールに直接影響を与えることなく、モジュールを追加、削除、またはリファクタリングすることができます。
  • テストの容易さ： 各モジュールは独立してテストできるため、システムの信頼性と品質が向上します。

これでモジュールの作成プロセスは終了です。次のトピックでは、モジュールの内部要素（エンティティ、値オブジェクト、列挙型、コマンド、クエリ、API、統合など）をどのように構造化するかについて説明します。

処理されていないエラーが発生しました。 再読み込み 🗙