JHipsterドメイン言語(JDL) - アプリケーション パーマリンク to " JHipsterドメイン言語(JDL) - アプリケーション"

概要 パーマリンク to "概要"

  1. 構文
  2. アプリケーションのオプション
    1. 基本の例
    2. 複数のアプリケーション
    3. エンティティを付与
    4. オプションを付与
  3. マイクロサービスワークフロー
  4. 完全なサンプルのブレークダウン
  5. 使用可能なアプリケーション構成オプション
  6. 関連項目

構文 パーマリンク to "構文"

アプリケーション宣言は、次のように行われます。

application {
  config {
    <アプリケーション・オプション名> <アプリケーション・オプション値>
  }
  [entities <アプリケーション・エンティティのリスト>]
  [<オプション>]
}
  • アプリケーションの設定キー/値は config の下に指定されます(applicationの中にある必要があります)。
  • 0、1、または任意のアプリケーション・オプションを指定できます(有効な場合)。
  • アプリケーション内で生成されるエンティティは、entitiesのリストにします。これは、アプリケーションでエンティティを生成するための 推奨される方法です。
    • これは省略できますが、その場合アプリケーション内でエンティティを生成するには、以下を行う必要があります。
      • アプリケーション内の別のJDLファイルから生成
      • またはCLIを使用
  • entitiesキーワードはオプションです。省略できますが、JDLファイル内のすべてのエンティティが アプリケーション内で生成されることになります。
  • アプリケーションには通常のオプション(dtoまたはservice)を持つことができます。詳細については次のセクションで説明します。

アプリケーションのオプション パーマリンク to "アプリケーションのオプション"

オプションの宣言(dto, service, skipServerなど)はJDLのアプリケーションでサポートされていますが、いくつかのルールがあります。

たとえば、次のJDLファイルがあるとします。

application {
  config {
    baseName app1
  }
  entities A, B, C
  dto * with mapstruct
}

application {
  config {
    baseName app2
  }
  entities C, D
  paginate * with pagination except D 
}

application {
  config {
    baseName app3
  }
  entities * except A, B, C, D, F
  service * with serviceClass
}

entity A
entity B
entity C
entity D
entity E
entity F

paginate * with infinite-scroll

このサンプルでは、いくつかのことがわかります。

  • JDLファイルには、A, B, C, D, E, Fの6つの宣言されたエンティティがあります。
  • 3つのアプリケーションapp1, app2, app3があります。
    • app1A, B, Cを使用します。
    • app2C, Dを使用します。
    • app3Eを使用します(* except A, B, C, D, Fにより)
  • 各アプリケーションではオプションとグローバルな オプションを宣言しています。
    • app1dto宣言をA, B and Cに対して行います。
    • app2paginate宣言をCに対して行います(除外があるため)。
    • app3serviceEに対して行います。
    • グローバルでpaginationを(全てのエンティティに対して)宣言します。

どのようにファイルが生成されるかを以下に示します。

  • app1
    • A: infinite-scroll の paginate(グローバルオプションはローカルオプションを上書きしません)と dto mapstructを使用
    • B: も同様のオプションを使用
    • C: も同様のオプションを使用
  • app2:
    • C: pagination の paginate(ローカルが優先のためinfinite-scrollは無し)
    • D: それまでのオプションがDを含めていないためinfinite-scroll の paginateを使用
  • app3:
    • E: infinite-scroll の paginateserviceClass の service

この例は、シャドーイングの原理を示しています。グローバルオプションはサポートされており、アプリケーションでオプションが宣言されていない限り、 宣言されたすべてのアプリケーションで使用されます。

また、次のスニペットはapp3の前のサンプルから引用したものです。

entities * except A, B, C, D, F
service * with serviceClass

基本としてapp3Eのみを使用し、アプリケーションのエンティティはserviceオプションを使用するという意味です。 これはEのみであり、AからFではありません。

最後に、Fエンティティどのアプリケーションにも存在せず、そのため、このエンティティは生成されません。

注:現時点では、すべての標準オプションがサポートされています。


パーマリンク to "例"

基本の例 パーマリンク to "基本の例"

application {
  config {
    baseName exampleApp
    applicationType gateway
  }
}

複数のアプリケーション パーマリンク to "複数のアプリケーション"

application {
  config {
    baseName exampleApp1
    applicationType microservice
    serverPort 9001
  }
}

application {
  config {
    baseName exampleApp2
    applicationType microservice
    serverPort 9002
  }
}

application {
  config {
    baseName exampleApp3
    applicationType gateway
    serverPort 9000
  }
}

エンティティを付与 パーマリンク to "エンティティを付与"

application {
  config {
    baseName exampleApp1
    applicationType microservice
    serverPort 9001
  }
  entities A
}

application {
  config {
    baseName exampleApp2
    applicationType microservice
    serverPort 9002
  }
  entities * except A
}

entity A
entity B
entity C

オプションを付与 パーマリンク to "オプションを付与"

application {
  config {
    baseName exampleApp1
    applicationType microservice
    serverPort 9001
  }
  entities A
  dto A with mapstruct 
}

application {
  config {
    baseName exampleApp2
    applicationType microservice
    serverPort 9002
  }
  entities * except A
  paginate C with pagination
}

entity A
entity B
entity C

完全なサンプルのブレークダウン パーマリンク to "完全なサンプルのブレークダウン"

例1:

application {
  config {
    baseName myMonolith
    applicationType monolith
  }
  entities * except C, D
}
application {
  config {
    baseName myGateway
    applicationType gateway
    serverPort 9042
  }
  entities * except A, B
}
application {
  config {
    baseName microserviceA
    applicationType microservice
  }
  entities C
}
application {
  config {
    baseName microserviceB
    applicationType microservice
    serverPort 8082
  }
  entities D
}
entity A
entity B
entity C
entity D
dto * with mapstruct
service * with serviceClass
paginate D with pagination

これらのアプリケーションおよびフォルダを生成すると、いくつかの処理が行われます。

  • 4つのアプリケーションが作成されます。
    • サーバーポートを8080とし、./myMonolith以下にmyMonolithを作成
    • サーバーポートを9042とし、./myGateway以下にmyGatewayを作成
    • サーバーポートを8081とし、./microserviceA以下にmicroserviceAを作成
      • サーバー・ポートを指定しなかったとしても、JHipsterはデフォルトでポートを設定します。
      • マイクロサービスの場合、デフォルトは8081です。
      • ゲートウェイとモノリスの場合は8080です。
    • サーバーポートを8082とし、./microserviceB以下にmicroserviceBを作成
  • 4つのエンティティが生成されます。
    • モノリス内にAB
    • ゲートウェイ内にCD
      • 最初のマイクロサービスにC
      • 2番目のマイクロサービスにD
  • microserviceオプションは、CおよびDに対して暗黙的に付けられます。
    • 2つのマイクロサービスで生成されるため、このオプションはデフォルトで設定されます。
  • オプションは前述と同じように機能します。

デフォルト値が存在しない場合、ジェネレータは(databaseTypeのように)デフォルト値を設定することに注意してください。 JHipster Coreはまったく同じ動作をしてくれます。


例2:オプションの使用 オプションのセクションを参照してください。


マイクロサービスワークフロー パーマリンク to "マイクロサービスワークフロー"

マイクロサービスを扱うのは難しい作業ですが、JDLには、エンティティを適切に処理するためのオプションがいくつか用意されています。 microservice <エンティティ> with <マイクロサービスアプリの名前>により、どのマイクロサービスでどのエンティティを生成するかを指定できます。

例えば、次のように設定します。

entity A
entity B
entity C
microservice A with firstMS
microservice B with secondMS

2つのJHipsterアプリケーション(’firstMS’と’secondMS’)を使用した場合、JDLファイルをインポートすると次のようになります。 次の2つのアプリケーションについて:

  • ‘firstMS’では、エンティティACが生成されます。
  • ‘secondMS’では、エンティティBCが生成されます。

Cは両方で生成されます。なぜなら、このエンティティが生成される場所を指定するマイクロサービスオプションがない場合でも 両方のアプリケーションで生成されるからです。

このJDLをモノリスアプリケーションにインポートすると、すべてのエンティティが生成されます(このJDL内には、モノリスは制約に関する オプションが無いため)。

注:同じエンティティを2つの異なるマイクロサービスで生成したい場合は、JDLファイルを更新するのではなく、 その都度、複数のJDLファイルを作成することで実現できます。

上記の例は次のような記述はできません。

entity A
entity B
entity C
microservice * except B with firstMS
microservice * except A with secondMS

結果はこうなります。

  • ‘firstMS’では、エンティティCのみが生成されます。
  • ‘secondMS’では、エンティティBCが生成されます。

なぜなら、構文解析時に、あるオプションが別のオプションと重複する場合には、後者が優先されるからです。 JDLを使用してマイクロサービススタック全体の作成もできます。例としてこのブログを参照してください


使用可能なアプリケーション構成オプション パーマリンク to "使用可能なアプリケーション構成オプション"

JDLでサポートされているアプリケーションオプションは次のとおりです。

あなたが探しているものではありませんか?通常のオプションをチェックしてください。

JDLオプション名 デフォルト値 指定可能な値 コメント
applicationType monolith monolith, microservice, gateway
authenticationType jwt jwt, session, oauth2 jwt
baseName jhipster
blueprint DEPRECATED 追加のブループリントの名前 blueprintsを参照
blueprints [] 追加のBlueprintの名前。マーケットプレイスを参照。内部で公開されているカスタムブループリントも含まれます 使用するBlueprint配列。例:[blueprint1,blueprint2]
buildTool maven maven, gradle
cacheProvider ehcache or hazelcast caffeine, ehcache, hazelcast, infinispan, memcached, redis, no モノリスやゲートウェイにはehcache、それ以外にはHazelcast
clientFramework angularX angularX, angular, react, vue, svelte, no
clientPackageManager npm npm
clientTheme none 何かを指定もしくはnone (yetiのように)動作することがわかっている場合は、任意の値を設定できます
clientThemeVariant 何かを指定もしくはnone (darkやlightのように)動作することがわかっている場合は、任意の値を設定できます。空欄も可
databaseType sql sql, mongodb, cassandra, couchbase, no
devDatabaseType h2Disk h2Disk, h2Memory, * * + プロダクションデータベースのタイプ
dtoSuffix DTO DTOsの接尾辞。空の文字列の場合はfalse。
enableHibernateCache true
enableSwaggerCodegen false
enableTranslation true
entitySuffix エンティティの接尾辞。空の文字列の場合はfalse。
jhiPrefix jhi
languages [en, fr] JHipsterで使用可能な言語 中括弧は必須
messageBroker no kafka, pulsar, no
nativeLanguage en JHipsterがサポートするすべての言語
packageName com.mycompany.myapp packageFolderオプションが設定
prodDatabaseType mysql mysql, mariadb, mssql, postgresql, oracle, no
reactive false
searchEngine no elasticsearch, couchbase, no
serverPort 8080, 8081 or 9999 アプリケーションのタイプに依存
serviceDiscoveryType no consul, eureka, no
skipClient false
skipServer false
skipUserManagement false
testFrameworks [] cypress, protractor, cucumber, gatling 中括弧は必須
websocket no spring-websocket, no

関連項目 パーマリンク to "関連項目"

通常のオプションはここにあります。