Lino で完全な .NET アプリケーションを構築する: ステップバイステップガイド

Lino CLI のインストールと構成

を使い始めるための最初のステップ Lino CLI 開発環境にツールをインストールすることです。 として配布されています。 ドットネット グローバル ツールこれは、コンピューター上のすべての.NET プロジェクトで使用できることを意味します。 インストールする前に、現在のテンプレートに必要な.NET SDK が利用可能であり、ターミナルが実行できることを確認してください。 dotnet .NET グローバル ツール ディレクトリが PATH。

ステップ 1: インストール

Lino CLI をインストール (または更新) するには、ターミナルで次のコマンドを実行します。

dotnet tool install --global Tolitech.Lino

重要な注意事項:

• すでにインストールされているバージョンがある場合は、次を使用できます dotnet tool update --global Tolitech.Lino 更新します。
• .NET グローバル ツール ディレクトリが PATH システムのコマンドが lino 正しく機能します。

ステップ 2: 言語を構成する

インストール後、CLI がメッセージ、プロンプト、ログで使用する言語 (またはカルチャ) を構成することをお勧めします。

lino preferences culture set

利用可能な言語から選択するように求められます。この設定により、すべての指示とプロンプトが一貫して希望の言語で表示されます。 この設定により、CLI のローカライズされたメッセージ、プロンプト、ガイダンスが変更されます。プロジェクトで生成されたエンティティ、サービス、モジュール、またはビジネス用語の名前は変更されません。

ステップ 3: 認証と登録

高度なテンプレート、Docker イメージの公開、外部サービスとの統合を含む、すべての Lino 機能にアクセスするには、認証される必要があります。

- まだ登録していない場合は、次のコマンドで登録します。

lino user register

- すでに登録済みの場合は、次の方法でログインします。

lino auth login

何が起こるのですか： CLI は認証トークンをローカルに保存するため、保護されたリソースへのアクセスが必要なコマンドを、使用するたびにログインすることなく実行できます。 このトークンを非公開にし、異なる開発者、CI エージェント、またはマシン間で同じユーザー プロファイルを共有しないようにします。

ステップ 4: 検証

インストールと認証が成功したことを確認するには、次のコマンドを実行します。

lino --version

コマンドがインストールされているバージョンを返した場合は、使用を開始する準備ができています。 Lino CLI あなたのプロジェクトで。

MyApp プロジェクトの作成

このステップでは、 Lino CLI。 このプロジェクトは、サービス、モジュール、フロントエンド、およびすべてのイベントの統合の作成を実証するための基礎として機能します。 Lino プロジェクトは、ソリューションを含む単なるフォルダーではありません。サービス境界、共有ライブラリ、Aspire ホスト、フロントエンド フレームワーク、テスト、パッケージ管理、アナライザー、および次のコマンドが再利用する構成の規則を定義します。

ステップ 1: create コマンドの実行

新しいプロジェクトを作成するには、ターミナルで以下のコマンドを実行します。

lino project new

CLI は段階的にガイドし、次のような情報を求めます。

• プロジェクト名: 私たちは使用します MyAppただし、好きな名前を選択できます。
• 追加機能: コードアナライザー、分散キャッシュ、非同期イベントのサポートなど。

ステップ 2: 重要な機能の構成

このプロジェクトでは、最初から次の機能を有効にすることをお勧めします。

• コードアナライザー: コードが適切な実践と一貫した標準に従っていることを確認し、一般的な実装エラーを防止します。
• 分散キャッシュ: 複数のサービスを使用するシナリオでアプリケーションのパフォーマンスを向上させ、不必要なデータベース クエリを回避します。
• 非同期通信: サービス間の統合にイベントとキューを使用できるようにし、スケーラビリティと分離を確保します。

統合イベントを通じて通信する複数のサービスを作成するため、このプロジェクトではこれらのオプションをすべて有効にすることが重要です。 これにより、Lino を使用してモジュール式分散システムを構築する方法を理解できるようになります。

ステップ 3: 生成された構造

コマンドを実行してリソースを構成すると、CLI によって初期プロジェクト構造が生成されます。これには以下が含まれます:

• サービスとモジュールのフォルダー。
• フロントエンド テンプレート (該当する場合)。
• 初期キャッシュ設定、イベント、統合。
• ソリューション (.slnx) およびプロジェクト (.csproj) ファイルはコンパイルの準備ができています。

今あなたのプロジェクト マイアプリ 次の手順で構成するサービス、モジュール、エンティティ、フロントエンドを受け取る準備ができています。 続行する前に、生成されたソリューションを開いて実行します。 dotnet build 参照、ソース ジェネレーター、テンプレート、プロジェクト ファイル、および初期設定が一貫していることを確認します。

バックオフィス Web アプリケーションの追加

通常、完全なシステムには、ドメインを操作するために少なくとも 1 つの Web アプリケーションが必要です。このガイドでは、アプリケーションを次のように呼びます。 Backoffice 製品、カテゴリ、在庫、販売、その他のシステム情報を監視するための管理者、マネージャー、または運用ユーザー向けの内部インターフェイスを表します。

Web アプリケーションはドメイン サービスに代わるものではありません。これは、API を消費し、コマンドをトリガーし、クエリを参照し、サービスですでにモデル化されているルールと一致する画面を表示するための視覚的なエントリ ポイントとして機能します。

ステップ 1: create コマンドの実行

プロジェクトに新しい Web アプリケーションを追加するには、次を使用します:

lino web-app new

入力を簡単にするため、エイリアス lino webapp new も利用できます。実行中は Web アプリケーションに明確な名前を指定します。この例では Backoffice を使用します。

lino web-app new --name Backoffice

ステップ 2: 生成された構造を理解する

処理が完了すると、Lino は src/WebApps/<WebAppName> に Web App の初期構造を作成します。Blazor アプリケーションの場合、この構造には server/client プロジェクト、共有リソース、ローカライズファイル、API を利用するための clients、後で lino page new が使用する規約が含まれることがあります。

• ページ、コンポーネント、レイアウト、サービス、アプリケーション リソースのフォルダー。
• プロジェクト サービスによって公開される API を使用するために必要な HTTP クライアントとコントラクト。
• Web エクスペリエンスで使用されるローカリゼーション リソースと初期テンプレート。
• アプリケーションの種類でこの分離が必要な場合は、クライアント/サーバー プロジェクト。
• ページ生成時に再利用されるルート、ナビゲーション、統合の規則。
• 認証機能がプロジェクトに追加される場合、認証および認可との統合ポイント。

ステップ 3: フロー内で Web アプリを作成するタイミング

システムに Blazor インターフェースがあることが分かっている場合は、プロジェクト作成直後の早い段階で Web App を作成します。これにより、後から生成される services、modules、entities、APIs、pages が、それらを利用する Web アプリケーションと最初から整合します。

この流れが特に有用なのは、後から作成される services も、Blazor プロジェクトから利用される型付きの Api.Contracts と Api.Client プロジェクトを生成するためです。最初から Web App が存在していれば、domain、API、contracts、HttpClient、画面までの一連の流れを検証しやすくなります。

重要な注意事項

• バックオフィスは、生成された API を通じてデータを消費し、正しいサービスとモジュールでビジネス ロジックを維持する必要があります。
• 管理ページを公開する前に、認証、承認、役割、権限、およびアクセス ポリシーを確認してください。
• 複数の Web アプリケーションを作成できます。 Backoffice 内部と Site 対象者、権限、展開、または責任が異なる場合はパブリック。
• セキュリティ、ナビゲーション、展開、またはチームの所有権が困難になる場合は、同じ Web アプリ内でパブリック フローと管理フローを混在させないでください。

Web アプリケーションを作成したら、ガイドは、このインターフェイスで使用されるデータとビジネス ルールを提供するサービスとモジュールに進むことができます。

サービスとモジュールの作成

このステップでは、アプリケーションを構成するサービスとモジュールを構築します。 目的は、モジュール式でスケーラブルなアーキテクチャを作成し、製品、カテゴリ、在庫、販売、メディアなどのシステムのさまざまな領域が独立して進化できるようにし、一貫性を維持し、メンテナンスを容易にすることです。 サービスはデプロイメントと永続性の境界を定義します。モジュールは、モジュール式サービス内のビジネス領域を編成します。ファイルを作成する前に、ドメインのどの部分に独自のデータベース、独立したリリース、統合契約、または個別の所有権が必要かを評価します。

ステップ 1: サービスを定義する

最初に、明確に定義された責任を持つ次のサービスを作成します。

• Catalog (モジュール式) – 製品、カテゴリ、価格の管理を担当します。
• Sales – 販売と注文の処理を担当します。
• Stock – 在庫と移動の管理を担当します。
• Security – 認証、認可、ユーザー管理を担当します。

例の services を作成するには、service ごとに 1 つずつコマンドを実行します。Catalog の wizard では modular architecture を選び、その他は単純な境界に適した architecture を選択します。

lino service new --name Catalog
lino service new --name Sales
lino service new --name Stock
lino service new --name Security

コマンド実行中、CLI は次の情報を求めます:

• Service name: 例: Catalog;
• Display name and architectural style: 小さな境界には simple architecture を、service に独立した凝集度の高い領域がある場合は modular を選択します;
• Database: プロジェクトに最も適した技術を選択します (SQL Server、PostgreSQL など);

ステップ 2: services 内に modules を作成する

すべての services が modular である必要はありません。この project では、merchandising や pricing などの責務を分離するため、Catalog service だけが modules を持ちます。

Catalog service には次の modules を定義します:

• Merchandising – products と categories の管理;
• Pricing – prices、promotions、変更履歴の管理。

Catalog の modules を作成するには、次を実行します:

lino module new --service Catalog --name Merchandising
lino module new --service Catalog --name Pricing

モジュラーサービス内に必要なだけモジュールを作成できます Catalog。 さらに、複雑さによっては、一部のモジュールが将来的に独立したサービスになる可能性があります。 ここで示した分離は教訓的な目的のみであり、モジュール型組織の例として機能します。 モジュールを使用してフォルダーを作成するだけではありません。独自のエンティティ、ユースケース、API、移行、およびイベントでビジネス領域を保護する場合にそれらを使用します。

最終的なプロジェクト構造

サービスとモジュールを作成した後、ソリューションは次のような構造になるはずです。

MyApp/
└── src/
    ├── Aspire/
    ├── Integrations/
    ├── Services/
    │   ├── Catalog/
    │   │   ├── Modules/
    │   │   │   ├── Merchandising/
    │   │   │   └── Pricing/
    │   │   ├── MyApp.Catalog.Host
    │   │   └── MyApp.Catalog.Infrastructure
    │   ├── Sales/
    │   ├── Security/
    │   ├── Shared/
    │   └── Stock/
    └── WebApps/
        ├── Backoffice/
        │   ├── Services/
        │   │   ├── Catalog/
        │   │   ├── Sales/
        │   │   ├── Security/
        │   │   └── Stock/
        │   ├── MyApp.WebApp.Backoffice
        │   └── MyApp.WebApp.Backoffice.Client
        └── Shared/
            └── MyApp.WebApp.Shared
└── tests/
    └── Services/
        ├── Catalog/
        │   ├── Merchandising/
        │   └── Pricing/
        ├── Sales/
        ├── Security/
        ├── Shared/
        └── Stock/

構造の説明:

• Services/: すべてのシステム サービスが含まれており、それぞれが独自のビジネス ロジック、インフラストラクチャ、ホスティングで分離されています。
• Modules/: モジュラー サービス内のフォルダー。特定の機能を整理し、一貫したコードを維持できます。
• WebApps/: システムに関連付けられ、すでにサービスと統合されているフロントエンド。
• Shared/: サービスとフロントエンド間で共有されるライブラリとリソース。
• tests/: サービスとモジュールごとに編成された単体テストと統合テスト。

このモジュール構造により、各チームや開発者はシステムのさまざまな部分で独立して作業できるため、スケーラビリティ、メンテナンス、テストが容易になります。 サービスとモジュールを作成した後、実行します dotnet build プロジェクトがソリューション、ホスト Aspire、共有プロジェクト、およびテスト フレームワークに正しくアタッチされていることを確認します。

認証と認可の追加

認証と認可は、現代のシステムにとって不可欠な要素です。 認証はユーザーが誰であるかを証明します。認可は、このユーザーが実行できる内容を定義します。Lino CLI では、認証機能は、ユーザー、ロール、権限、トークン、アクセス ポリシー、および API との統合に必要なベースを生成します。

ステップ 1: 認証コマンドの実行

認証および認可機能を追加するには、次のコマンドを使用します。

lino feature auth add

CLI は次の手順を案内します。

• サービスまたはモジュールの選択: 認証アーティファクトをインストールする場所を指定する必要があります。 このサンプルプロジェクトでは、サービスを使用します Security、システムのセキュリティ ロジックをすべて一元化します。
• 追加の設定: ユーザー、ロール、権限、トークンのテーブルの作成、およびアクセス ポリシーの構成。
• トークンの有効期間: 製品のセキュリティポリシーに従ったアクセストークンおよびリフレッシュトークンの有効期限の定義。
• ユーザー識別子のタイプ: ユーザー モデルと生成されたコントラクトで使用されるタイプを選択します。

ステップ 2: 生成された構造

コマンドを実行すると、サービスが Security 次のようなファイルとフォルダーが含まれます。

• ドメイン/エンティティ: ユーザー、ロール、権限、トークンの集計、エンティティ、ルール。
• インフラストラクチャ/永続性: データベース構成、Entity Framework マッピング、セキュリティ テーブルの移行。
• 応用： コマンド、クエリ、ハンドラー、認証サービス、トークン生成、資格情報の検証、および権限のチェック。
• API/ホスト: ログイン、ログアウト、登録、リフレッシュトークンおよび保護された操作のためのエンドポイント。
• Web アプリとの統合: Web アプリケーションが存在する場合の認証されたフローのサポート。

これにより、アプリケーションは堅牢な認証と詳細なアクセス制御を備え、複数のユーザーとさまざまなレベルの権限をサポートできるようになります。 それでも、生成されたコードは、最終的なセキュリティ レビューとしてではなく、強力な基盤として扱われる必要があります。実稼働前に、トークンの有効期間、権限の設計、パスワード ポリシー、HTTPS、シークレット、レート制限、ログ、展開構成を確認します。

Background Jobの追加

私たちが構築しているような分散型モジュール型システムでは Lino CLI、すべてのサービスが相互に直接通信するわけではありません。 情報交換の一貫性と信頼性を確保するために、統合イベントを使用します。 ただし、これらのイベントを効率的かつ非同期的に処理するには、 Background Job。

Lino は標準を使用します Outbox パターン サービスによって生成されたすべてのメッセージが送信前に確実に記録されるようにします。 これにより、次のことが達成されました。

• サービスの障害または再起動が発生した場合のイベントの損失を回避します。
• 同じメッセージが 1 回だけ送信されるようにしてください。
• 配信失敗の場合にメッセージの再処理を許可します。
• イベント処理をメインのアプリケーション ロジックから分離し、パフォーマンスとスケーラビリティを向上させます。

ステップ 1: コマンドの実行

Background Jobのサポートをプロジェクトに追加するには、次のコマンドを実行します。

lino feature background-job add

CLI では、Background Jobがインストールされるサービスを選択するように求められます。一般的には、次のようなイベント制作を一元化するサービスを選択します。 Catalog または Sales。 現在のオプションでは、ウィザードはモジュール、ジョブ ライブラリ、Outbox イベントを処理するかどうか、スケジュール、バッチ サイズを要求することもできます。現在のテンプレート フローは、定期的なジョブの実行に Hangfire を使用します。

ステップ 2: 実行の構成

構成中に、以下を定義できます。

• チェック間隔: Background Jobがテーブルをチェックする頻度を決定します Outbox 新しいメッセージの場合。間隔が短すぎるとリソースの使用量が増加する可能性があり、間隔が長すぎるとイベント配信が遅れる可能性があります。
• 一度に処理されるレコードのバッチ: 実行ごとに読み取って送信するイベントの数を制御します。バッチを大きくするとパフォーマンスが向上しますが、より多くのメモリと処理が必要になります。
• 取得ポリシー: メッセージの送信に失敗した場合に、ジョブが再送信を試行する回数を構成できます。

これらのパラメーターは、システムのサイズ、マシンの容量、および予想されるイベントの量によって異なります。

ステップ 3: 生成された構造

構成後、プロジェクトにはテーブルからのメッセージを処理できるBackground Jobが用意されます。 Outbox 各サービスで。

1. このユースケースでは、ドメインを変更し、ドメインまたは統合イベントを記録します。
2. 作業単位は、ビジネス データと Outbox からのメッセージを同じトランザクションに保存します。
3. Hangfire は、保留中のメッセージをバッチで読み取る定期的なジョブを実行します。
4. 非同期通信が有効な場合、メッセージは RabbitMQ などの構成された統合エンジンにパブリッシュされます。
5. 完了、失敗、古い、またはスタックのメッセージは、ジョブ用に生成されたロジックと構成によって処理できます。

これにより、すべての統合イベントが確実かつ効率的に処理され、メイン システムのパフォーマンスに影響を与えることなく、複数のサービスとモジュールが非同期通信できるようになります。 最も重要な運用ルールは、トランザクション境界を明確に保つことです。Outbox 経由で送信する必要があるイベントは、それが表すビジネス変更と同じトランザクション フロー内で作成する必要があります。

エンティティと列挙の作成

このセクションでは、アプリケーションのエンティティ、列挙、Value Objectの設計について詳しく説明し、各項目がどのサービスとモジュールで作成されるかを示します。

1. エンティティの作成 Category

Catalog サービスと Merchandising モジュールに Category entity を作成するには、次を実行します:

lino entity new --service Catalog --module Merchandising --name Category