試験について考えてみましょう。

flowchart LR

一次試験 --> 二次試験 --> 最終試験

次に、受験生の目線で考えてみましょう。

stateDiagram-v2
direction LR

[*] --> 一次試験
一次試験 --> 一次選考通過
一次試験 --> 一次選考落選

一次選考通過 --> 二次試験
二次試験 --> 二次選考通過
二次試験 --> 二次選考落選

二次選考通過 --> 最終選考
最終選考 --> 合格
最終選考 --> 不合格

試験を開催する側と受験する側でモデルが違います。

つまり「アクターによってユースケースが違う」モデルです。

モデルが違うのであれば、勿論Repositoryも分割します。

interface PrimarySelectionRepository //一次試験

interface SecondarySelectionRepository //二次試験

interface FinalSelectionRepository //最終試験

問題になるのは受験生のモデルです。

今回はモデルひとつにつきひとつのRepositoryを作りました。

interface ExamineeInPrimarySelectionRepository //一次選考中
interface PassedPrimarySelectionRepository //一次選考通過
interface FailedPrimarySelectionRepository //一次選考落選

interface ExamineeInSecondarySelectionRepository //二次選考中
interface PassedSecondarySelectionRepository //二次選考通過
interface FailedSecondarySelectionRepository //二次選考落選

interface ExamineeInFinalSelectionRepository //最終選考中
interface PassedFinalSelectionRepository //最終選考通過
interface FailedFinalSelectionRepository //最終選考落選

このように、状態ごとにRepositoryを作るパターンもあります。

特に、状態遷移に制約がある場合には有効です。

<aside> 💡 一次選考を通過しないと二次試験は受験できない、のような、状態遷移をするための条件があることを制約と呼んでいます。

</aside>

状態とは

受験生のモデルでは試験をするごとに通過又は落選し、次の試験がある場合は受験していました。

受験している人は同じ人なので受験idは同じものを使いまわしたほうが良いでしょう。(順不同の属性を持っている場合にはExamineeIdRepositoryを作る可能性もあります)

このような、同一性があるものの、タイミングによって持っているデータが変わるようなことを状態と呼んでいます。

一方で、試験のモデルでは一次試験、二次試験、最終試験を扱っていましたが、これは状態と呼べるでしょうか。