Skip to main content
Version: Next

デザイン

ビジネス分析#

ビジネス境界#

このシステムには、チケットの残券管理部分のみが含まれています。つまり、残りの座席を照会し、チケットを購入し、座席を減らします。

注文情報の生成、支払い、フロー制御、要求風制御などは、この議論の範囲外です。

ビジネスユースケース#

  • 残券を照会し、2つの駅間で利用可能な車両数と残りの座席数を照会することができます。
  • チケットの残券を照会し、特定のチケットを照会し、各駅の間に残っている座席の数を確認できます。
  • 座席指定をサポートし、お客様は特定の座席と座席を選択し、チケットを購入することができます。

難しい分析を実装します#

チケット管理#

列車のチケット管理の難しさは、実際には、残りのチケット在庫の特殊性です。

SKU を最小単位とし、各 SKU は互いに独立し、互いに影響しない一般的な電子ビジネス商品です。

列車のチケットは、販売されたチケットの終点によって影響を受けるため、異なります。ここでは、単純な論理モデルを組み合わせて、この特殊性を詳しく説明します。

ここで、a、b、c、d の 4 つのサイトをそれぞれ通過する 1 つの車両が存在すると仮定し、同時に、車両に 1 つの座席しきがあると仮定して、シナリオを簡略化します。

そして、誰もチケットを購入する前に、このチケットの残りの部分は次のようになります:

始点と終点残券
a,b1
a,c1
a,d1
b,c1
b,d1
c,d1

現在、a,c のチケットを購入している顧客がある場合。座席が 1 つしきらないので、 c,d 以外の残券はありません.残りのチケットは次のようになります:

始点と終点残券
a,b0
a,c0
a,d0
b,c0
b,d0
c,d1

より明確にすると、顧客がフルチケットa,dを購入した場合、残りのチケットはすべて0になります。なぜなら、この席はいつも乗客が座っているから。

これは、列車のチケットの特殊性です:同じ列車の同じ座席で、各始点と終点の残券の数は、販売されたチケットの始点と終点によって影響を受けます。

少し伸ばすと、同じ車の異なる座席の間にそのような影響がないことを簡単に引き出すことができます。

残券照会#

前のセクションで説明したように、残りのチケットの在庫の特殊性のために。同じチケット a、b、c、d の場合、6 つの可能なチケットオプションがあります。

また、選択したカテゴリ数の計算方法は、実際には n 個のサイトで 2 つの組み合わせ数 (c(n,2) を選択することです。

34 のサイトを通過する車両がある場合、可能な組み合わせは c (34,2) = 561 です。

存在する可能性のある複数のクエリに効率的に対処する方法も、システムが解決する必要がある問題です。

クラプトトラックのボディデザイン#

Train Ticketing System Design

同じバスの各座席を1つのClaptrap - SeatGrainとして設計します#

Claptrap の State には、基本的な情報が含まれています

名前説明
IList<int>Stations始発駅から始点、終点で終わるパスステーションの id リスト。主要なチケット購入時に検証します。
Dictionary<int, int>StationDicルート ステーション ID のインデックス逆ディクショナリ。Stations は、クエリを高速化するために対応する id-index のディクショナリである index-id のリストです。
List<string>RequestIds重要なプロパティ。各区間で、購入されたチケットのチケット ID。たとえば、index が 0 の場合、駅 0 から駅 1 へのチケット ID を表します。空白の場合、サブスクリプションはありません。

このデータ構造の設計により、2 つのビジネスを実現できます。

購入できることを確認します#

2 つのステーション ID を渡して、この SeatGrain に属しているかどうかを照会できます。また,始点から終点に対応するすべての区間を問い合わせる.この RequestIds から、すべての区間にチケット Id がないかどうかを判断すればよい.そうでない場合は、購入することができます。チケット ID が既にある段落がある場合は、もう購入できません。

たとえば、現在の Stations の場合は 10,11,12,13 です。 RequestIds は 0,1,0 です。

さて、10->12のチケットを購入する場合、RequestIdsの2番目の区間はすでに購入されています。

ただし、10->11 のチケットを購入する場合は、RequestIds の最初の区間はまだ購入されていないので、問題はありません。

購入#

始点と終点を RequestIds 内のすべての区間に対応してチケット Id を購入すればよい.

同じバスのすべての座席の残券を1つのクプトラック-TrainGranとして設計します#

Claptrap の State には、いくつかの基本的な情報が含まれています

名前説明
IReadOnlyList<int>Stations始発駅から始点、終点で終わるパスステーションの id リスト。メイン クエリで検証します。
IDictionary<StationTuple, int>SeatCount重要なプロパティ。StationTuple は始点と終点を表します。コレクションには、すべての可能な始点と終点の残りのチケットが含まれています。たとえば、上記のように、車両が 34 か所を通過する場合、ディクショナリには 561 のキーと値のペアが含まれます

上記のデータ構造に基づいて、SeatGrain が注文を完了するたびに、対応する情報をその Grain に同期するだけで済みます。

たとえば、a,c でチケットが 1 回購入された場合、a,c/ a,b / b,c の残りのチケットを 1 つ減らします。

これは、このフレームワークに組み込まれている Minion メカニズムを使用して実現できます。

これは「最小競合リソース」よりも大きな設計であることを言及する価値があります。クエリ シナリオは、そのビジネス シナリオで絶対に高速である必要はありません。これにより、システムの複雑さが軽減されます。

Id#

Train Ticketing System Id