この記事は株式会社ビットキー Advent Calendar 2023の20日目の記事です。
bitlock という スマートロックのIoT製品を取り扱うスタートアップで、ドメイン駆動設計(DDD)のモデリングの一環として sudo モデリング を実践した際の知見や気づきをまとめています。
0. 留意事項
IoTと記載していますが…本記事では、単体でネットワークにつながるデバイスではなく、スマホと介してネットワークとつながり制御を行うスマートロックを主たるデバイスとして取り扱っています。
本記事は2022年のアドカレ記事の続編となります。よろしければぜひ前の記事(「[第一弾] IoTスタートアップの事業の変遷とドメインの進化」)も読んでいってください。
本記事で取り扱っているモデリングの完成度はかなり高いわけではなく、作成している資料も改善ポイントが多くあると思います。実際の現場において限られたリソースで開発を進めていく上で、「モデリング」という要素を効果的な活用を試みた軌跡として読んでいただけますと幸いです。※ 改善ポイント等ありましたら、コメントにて指摘いただけますと幸いです。
1. はじめに
本記事ではログラス松岡さん(Twitter)が提唱している sudoモデリング を現場で実践した際の実例と感じたことを記載します。
できるだけ実例の部分をそのまま記載するようにしています。
このような記事を投稿しようとした背景として、どのように ドメイン駆動設計 への取り組み方については非常に優れた書籍が多数あります。しかし、実際のプロダクト開発での実例を知る機会があまりなく、具体事例をイメージしづらいと感じています。
今回実際に sudoモデリング を実践した際の資料も合わせて記載しているので、一つの実例として今後の開発の助力としていただければ幸いです。
1-1. 自己紹介
株式会社ビットキーで開発をしています (Twitter)。フロントもバックエンドも開発しますが、バックエンド開発が好きで、TypeScriptをよく利用します。物事を抽象的にとらまえて構造化して設計/実装するのが好物です。
ビットキーの事業は大きく Home(暮らし)、 Work(働く) 、 Experience(非日常) の3つ領域に分かれており、その中でもHome 領域を担当しており、homehub を呼ばれるプロダクトの開発に従事しています。
1-2. sudoモデリングとは
松岡 幸一郎さんが提唱しているモデリング手法です。こちらの記事に記載されている内容をもとに実践しています。
記事内では sudoモデリング に関して以下のように紹介されています。
DDDにおいてシンプルで成果が出しやすいモデリング手法について紹介
さまざまなモデリング手法から、DDDで実装に落とし込むための最小限のラインナップとして 筆者が抽出したもの
また、sudoモデリング とは、システム相関図(S)、ユースケース図(U)、ドメインモデル図(D)、オブジェクト図(O)の4つを軸にした手法です。
1-3. sudoモデリングに至るまでの背景
約7ヶ月前の2022年5月あたりから DDD を段階的にプロダクトに導入していました。(詳細は過去投稿しているQ別記事(「課題解決指向型ドメイン駆動設計 〜導入編〜」)を参照してください)
優先的に解決したい課題は「堅牢」「知識の集約」でした。また、既に実装済みのプロダクトのリファクタリングも多く、新規にモデリングをするよりは、 オブジェクト指向 の仕組みを如何に適用していくか、に重きをおいていました。
その後しばらくして、新規機能開発をする際に既存の構造を見直すのが必要となりました。そこで、モデリングの進め方として sudoモデリング を参考に実施することに決めました。
sudoモデリング を選択した理由は、低コストで実践が可能であり、かつ実績があるものだったからです。
2. ドメインを拾い上げる
まずはドメインの知識を把握し整理していきます。
良い機会でしたので、ビットキーの私が所属しているHomeの領域で取り扱っているドメイン(業務知識)の内容についてまとめました。
…が、1つの記事にまとめきるにはボリューミーすぎたため記事を分けて記載しています。
ドメイン知識の詳細については「[第一弾] IoTスタートアップの事業の変遷とドメインの進化」を参照ください。
本記事ではドメイン知識は記載せずにどのようにsudoモデリングに取り組んだかを主として記載しています。
ドメインが気になる！一度本記事をお読み頂いた上で、ドメインの知識を補填した上で理解を深めたい！…と思っていただいた方はぜひもう一つの記事も読んでいただければと嬉しいです。
2-1. ドメインについて
本記事で取り扱う内容はスマートロックに関するものです。
特に B to B to C の領域で賃貸物件を対象とした内容となります。
ビジネスとの構造としては以下になります。
- 賃貸物件を管理している管理会社が、管理している物件にスマートロックを設置する
- 管理会社が物件の入居者にデジタルなカギを発行する
- 入居者は管理会社から受け取ったデジタルなカギで扉の鍵を解錠することができる。スマホアプリから解錠することができます。
bitreader+というデバイスを追加で利用することで、スマホアプリでの解錠だけでなく、NFCカードやパスコードでの解錠が可能となります。
もっと詳細の内容は別記事に記載していますので、よろしければ読んでみてください。ビットキーの事業の変遷と合わせて、求められるドメインの変化をまとめています。
3. モデリングの前に大枠を整理する
sudoモデリング を実践する前に実施した、既存の構造の整理を記載しています。
sudoモデリング の雰囲気を見たい方は本章を飛ばして4章を参照ください。
3-1. なぜ整理を実施したか
前提となる概念や用語をある程度整えておかないと、せっかくモデリングしたものの共通認識をとれず破綻するリスクが大きいと判断したためです。
このタイミングでゼロから概念を考え直して整理しなおした…というよりは今までの知見を集約して整理した形になります。
また一部はある程度整理されていたものも多くあります。また実際に sudoモデリング を進める過程であらたな気づきをえて改善しながら進めている部分もあります。
3-2. 「ヒト」「モノ」「空間」のコア要素の整理
これまで培ってきた知見をもとに中心の要素となる「ヒト」「モノ」「空間」の概念を整理しています。
特にビットキーにおいては、空間にスマートロックを設置して、指定の空間にアクセスする権利があるヒトが、それを実現できるようにカギを発行する…という仕組みがベースとなる機能が多数あるため「空間」をコア要素としてとりあげています。
特に「ヒト」「モノ」「空間」についてはWorkなどの他の事業領域においても適用できるようにできるだけ抽象的に整理しています。
「空間」
「空間」はアクセスするための制御がかかる単位を一つの軸として整理をしました。
建物、専有部。場合によっては、フロアやラウンジなど。(特定の階層に住んでいる入居者のみ特定のフロアに入れるや、ラウンジに入ることができる…などの制御を実現することを考慮したためです。)
「ヒト」
「ヒト」は空間に対する関わり方を一つの基準とし次のように整理しました。
「モノ」
「モノ(≒デバイス)」は有する機能を基準とし次の3つの分類を用いて整理しました。
- LockDevice : 「解錠」する機能を有する。扉に設置することで、扉を解錠することを可能とする。
- AuthDevice : 「認証」する機能を有する。NFCカードや、パスコードが利用可能かどうかをチェックすることを可能とする。
- LinkDevice : 「接続」する機能を有する。ネットワークと繋がり遠隔操作や状態の取得をすることを可能とする。
デバイスによっては、LockDevice とAuthDevice など複数の機能を有する場合もありますが、LockDevice としての仕様と、AuthDevice としての仕様とを整理することで全デバイスを一つの基準で統合的に管理することが可能となりました。
3-3. 解錠手段の整理
次に解錠手段を以下の3つの分類をもとに整理しました。
-
Download Unlock: デジタルなカギを端末にダウンロードして、LockDeviceになげることで解錠することができる
(例) - homehub app (スマホアプリ)を操作することで解錠する - Apple Watch に利用可能なカギをダウンロードして解錠する
-
Authentication Unlock: NFCカードやパスコードなど特定の情報をAuthDeviceにインプットし、そのインプットをチェックして解錠可能な場合に、AuthDeviceからLockDeviceに対して解除コマンドが実行され解錠することができる。
(例) - AuthDeviceに利用可能なNFCカードの情報が事前に登録されており、解錠することができる - AuthDeviceがネットワークにつながっており、ネットワーク経由で解錠可能な手段かチェックしたうえで解錠を行う
-
Remote Unlock: ネットワークに接続されているLinkDeviceを経由して、遠隔で解錠することができる。
3-4. アクセスコントロールという概念の導入
homehubのプロダクトがより価値を発揮するのは、個別にカギを発行して利用できるようにする体験 ではなく、入居契約などの他の業務トランザクションと連動して必要な権利が利用できる状態 を実現することです。
なおここでの必要な権利とは、自分が借りた部屋の中に鍵を開けて入ることができる...といった 空間にアクセスすることができること としています。
プロダクトローンチ当初は、各処理が実装されている箇所に個別に「入居契約があるからこの期間でカギを発行する処理を実装しよう！」といったように、各業務トランザクションの処理ごとにカギの発行処理が散らばってしまっていました...。これは不具合を誘発したり、可読性を低下させたり...様々な問題を引き起こします。
これらをまとめるために 「だれ」が「どこ」に「いつ」「なに」でアクセスすることができるのか という概念を中心に制御する整理としました。(これをアクセスコントロールと呼称します)
例えば…
-
管理会社が入居者にカギを発行する場合には
-
「ビット太郎」は「ビットレジデンスの304号室」を「2022/01/01〜2023/12/31」の期間で入居契約をしている。
-
その結果「ビット太郎」は「ビットレジデンスの304号室」を「2022/01/01〜2023/12/31」の期間で「スマホ」と「NFCカード」で解錠することができる (※ 解錠手段は設定などに基づいてきまるものとする)
-
これを実現するために、デジタルなカギや、NFCカードを登録するための権利が発行される。
-
-
内見予約の場合には
-
「ビット内見仲介業者」の担当者は「ビットレジデンスの304号室」を「2022/01/01 12:00〜2022/01/01 15:00」の期間で、内見する予約をしている
-
その結果「ビット内見仲介業者」の担当者は「ビットレジデンスの304号室」を「2022/01/01 12:00〜2022/01/01 15:00」の期間で、「パスコード」で解錠することができる (※ 解錠手段は設定などに基づいてきまるものとする)
-
これを実現するために、所定の期間内で利用可能なパスコードを内見予約サイトやAPI連携で取得することができる。
-
といった整理をしました。
この概念の整理はHomeのプロダクトだけでなく、Workなど他の事業領域においても共通で適用できるように整理しています。
3-5. 「認証」「認可」の補足説明
ビットキーでは解錠の仕組みを実現するうえで、「認証」「認可」を取り扱う bitkey platform (以降BKPと略称)というマイクロサービスを利用して実現しています。
このマイクロサービスは抽象的なIFで実現されているため詳細は省きますが、
- 誰がどの「カギ穴」を解錠することができるか
- どの解錠方法(NFCカードやパスコード等)が、どの「カギ穴」を解錠することができるか
- 上記の権限の付与 / リクエスト / 承認
などを取り扱うIFとなっています。
このプラットフォームであるBKPでは「認証」と「認可」の洗練された要素のみを取り扱っています。
LockDeviceにどの「カギ穴」が紐付けられているかや、入居契約としてどんな情報が管理されているから、だれがどの期間どの「カギ穴」を解錠する権限を有しているか…といった部分をhomehubなどBKPを利用しているサービスで管理をします。
4. いざモデリング！
上記で整理したドメインをもとに既存の構造を見直しを行いました。
もともと限られたリソースで多くの機能を開発していた都合もあり、各機能やピンポイントのリリースに合わせて局所最適化を繰り返してきました。そのため、機能やプロダクトをまたぐ修正が必要なときにあちらこちらで整合性をとるのがきつい…というシチュエーションが発生しやすい状態となってしまっていました。
今回これを改善するために機能/プロダクト横断で影響しうる修正でかつ重要な構造を整理して必要な部分は刷新する判断をしました。扱う業務的な内容が増え、利用者数も増加し、リリースの速度よりも品質のウェイトが大きくなった結果、既存の構造を見直す必要がでてきたためです。
4-1. SUDOモデリングのお題
4-1-1. 概要
「入居/空室モード」の対応
4-1-2. 背景
B to B to C の領域において必要となった機能で、実際に開発してリリースした機能となります。
市場のニーズとして、賃貸物件の入居者が退去した後には、入居者が登録した「NFCカード」や「パスコード」が利用できないようにする必要があります。普通に考えたら当然のことと思います。
しかしながらここにはHWを取り扱うが故の難しさがあります。「NFCカード」や「パスコード」が利用可能なものかチェックするデバイスは、オフラインで解錠できる仕組みとなっており、そのため、利用できる「NFCカード」や「パスコード」を廃止するためには、現地で何かしらの操作が必要となります。
※ 賃貸物件の場合、空室中はネットワークがつながっていないことが大半であるためオフラインでの操作を前提とする必要があります。
賃貸領域においては必ず退去立会いや現状回復工事などの作業が行われることが大半ですので、だれかしらが現地に赴くことの障壁は大きくありません。ですが、スマホを利用できない業者や作業員が一定数存在します。
そのため、スマホがなくても特定のパスコードを入力することで、入居者が登録した「NFCカード」「パスコード」を利用できなくする機能を開発する必要がありました。
(これを実現するためにはデバイスに組み込まれているFirmwareの開発も必要。弊社ではHardware, Firmwreの開発チームもあり自社で開発しているためこの手のHardware / Firmwareも巻き込む必要がある機能改修を行いやすい環境にあります。)
4-1-3. 実現したいこと
- NFCカードやパスコードが解錠可能かをチェックする機器に任意の複数の「モード」を保持できるようにする
- 機器で制御される複数の「モード」に対して、homehubにおいては「入居」と「空室」といったドメインを紐付けて2つの「モード」を取り扱えるようにする
- 特定のパスコード(以降スイッチコードと呼称)を入力することでモードを切り替えることができる
- スイッチコードは固定のパスコードと一定時間で切り替わるTOTPから管理会社の運用に応じて選択できる
- 入居者が登録するNFCカードやパスコードは「入居」のモードでしか利用できないものとしてデバイスに登録する。また入居のモードから空室のモードに切り替わった際に以降利用できないようにデバイスから削除対象としてデバイスに登録をする。
- 内見や現状回復工事の際に利用するNFCカードやパスコードは、「空室」のモードでしか利用できないものとしてデバイスに登録する。空室モードから入居モードに切り替わった後に空室モードとなった場合に再度利用できるものとしてデバイスに登録を行う。
- 上記入居/空室モードによる制御は管理組織の運営方針によって変わるため組織ごと、建物ごとに利用する/しないを制御することができるようにする
4-1-4. 補足
さて、この機能を実現するのはそこまで難しくないように思います。
ただし、この機能は非常にセンシティブで、登録する解錠方法がどのモードで利用可能かの判定を誤ると解除できるべき手段で解錠できず、また解錠できるべきでない解錠方法で解錠できてしまう…という事象に繋がりえます。(カギなので当然ではありますが…)
また、入居者がhomehub appを利用して解錠可能な手段を登録する導線、管理会社が設置や設定の変更時にToBが利用するアプリとで裏側の仕組みが異なっており、今後の機能拡張の際など整合性を壊してしまい、問題を起こしてしまう可能性があります。
なので、入居/空室モードの対応の制御の処理はまとめて管理できるべき必要があります。
今回sudoモデリング を用いて整理をした上で、仕組みも整え直すこととしました。
4-2. sudoモデリング実施結果
実際に sudoモデリングを行った際に作成した結果を記載します。
原則的には提唱されている sudoモデリング の進め方に準拠しつつ、今回のケースに置いて効果的に開発を進める上でどのように実行したかと実施してみて感じた所感/得られた知見をまとめていきます。
4-2-1. S: システム関連図
※ 記載されているプロダクトの補足説明
- homehub Crew : 管理会社の社員などが、賃貸物件に bitlock (スマートロック)を設置するために利用するスマホアプリ
- homehub App : 賃貸物件の入居者などが、日々の暮らしの中で自宅の bitlock (スマートロック)を開錠するために利用するスマホアプリ
- homehub Admin : 管理会社の社員などが、賃貸契約の管理や鍵の配布などのオペレーションを行うための web アプリ
■ sudoモデリング上の定義
開発するシステムと、関わりのあるアクターや外部システムとの関連を示す図
■ どのような方針で作成したか
「利用者とプロダクトとの接点の全体像を理解すること」を達成するための図。と解釈して作成をしました。
今回は実際のSWのプロダクトを介さず、直接デバイスを操作するシチュエーションもあるのでデバイスも追加して記載しています。
また利用者とプロダクトの接点がぱっとみて把握しやすいように色もつけて表現をしています。
■ 所感
チーム人数が多くなく開発メンバーはほぼ全員把握済みの情報なので、資料を記載することに積極的ではありませんでした。
しかしながら、実際にQA評価の担当者やビジネスサイドのヒトにも見せて、大前提をあわせることができるというメリットや、新しいメンバーがジョインした時のざっくりとした全体像を前提知識としてインプットする…という点において十分にメリットがあると感じました。
作成するコストも高くないため、原則として作成する…といった整理で良いと考えています。低いコストで発生し得る根本の認識相違を一定解消することができるためコスト対効果は高いと考えているからです。
記載は図でなくとも表でも成立させることができるとは思いますが、図の場合には関連性を示すことができるので図を用いて記載するのが良いと考えます。
プロダクトや利用者は属性に応じて色や図を変えてあげるとより、視認性を増すことができると思います。
「利用者とプロダクトとの接点の全体像を理解すること」をより効果的に実現するために、必要に合わせてカスタマイズすればよいと思います。
■ 今後の運用予定
新規機能開発時に作成をする予定です。特に複数プロダクトにまたがる修正の場合には必須で良いと考えています。
4-2-2. U: ユースケース図
■ sudoモデリング上の定義
ユーザーの要求に対するシステムの振る舞いを定義する図
■ どのような方針で作成したか
利用者 × プロダクトごとに記載しています。
ユーザーの要求に対するシステムの振る舞いを定義する図として記載しています。
…が、
もともとこの sudoモデリング を実施する前に、必要なストーリーの一覧を
利用者 × プロダクトの粒度で作成していたので、この図は一覧の書き写しとほぼ同等となってしまいました。
↓ 作成していたストーリー一覧
■ 所感
ストーリー一覧はNotionのテーブルを利用して記載しているのですが、こちらのほうが絞り込みや並び替え、場合によっては詳細のメモ等の記載もしやすいので、今の運用においては、明示的にユースケース図を作成しなくてよいかなと感じています。
図示することで、図の位置やつなぐ線によって何かしら意味のある関連性を表現できればよいのですが、うまいこと意味のある表現することが難しかったため、一覧の表現の仕方で良いのではと判断しています。
(※ もしかしたら記載の仕方がうまくないだけなのかもしれません…)
■ 今後の運用
作成しないくて良いと考えています。
利用者 × プロダクトの粒度で何を実現する必要があるかの情報は何かしらの方法でまとめる必要があり、現時点ではNotionもしくはJiraにてまとめるが効果的と考えています。
※ 最終的にはjiraに起票はします。その前段階で規模等に応じてNotionでまとめるか否かの違いになります。
しかしながらメンバーによっては図示されていた方が、視覚的に理解しやすい！…という意見もあったので、チーム状況によって運用を変えたほうが良いのかもしれません。
4-2-3. O: オブジェクト図
※ 一部実際の成果物とは、表現を変えたり簡易的に記載している箇所があります。
■ sudoモデリング上の定義
ドメインモデルの具体例を記した図
■ どのような方針で作成したか
以下の方針に則って記載をしています。
- オブジェクトの代表的な属性を書くが、メソッドは書かなくてよい
- 「ルール/制約(ドメイン知識)」を吹き出しに書き出す
- オブジェクト同士の関連を示す
- 今回の主たる修正が必要な部分をオレンジの色で記載する
建物の中の専有部に設置されたAuthDeviceで利用可能な、NFCカードやパスコードの情報をまとめています。
ドメインモデル図より先にオブジェクト図を記載しています。
できるだけ主要な要素に絞ったうえで具体的に表現するように心がけています。一度要素を記載したうえで削除できる要素は削除するようにしています。
■ 所感
これが一番の収穫でした。
いままで各要素(モデル相当)の説明やソース上のコメントなどで記載するように心がけていましたが、同じチームの開発者にも適切に伝えきれないことが多々発生していました。
対象のモデルにもよるのですが、抽象度が高ければ高いほど具体的なイメージが付きづらく実際に関連する開発を進めていくと認識が食い違っていた…みたいなことが多々発生していました。また認識をあわせる事ができていたとしても、解釈する側が利用している実装などをみて使い方は立ち位置を把握せざるおえないこともありました。
具体的なサンプルをベースに記載することで、この問題を一定解消することができたと思っています。
またこの図は開発無いだけでなくQAチームやビジネスサイドの人間にも共有ができ、実際にQAチームに共有することでいつも以上に精度の高い評価を低コストで実現することができたと思っています。
この資料を資産として定期的にメンテナンス対象とするかは微妙なところで、現在はこの資料が明らかな虚偽となってしまう場合にのみ適宜修正するにとどめています。個人的には、使い捨ての扱いとしてもメリットは大きいと感じており、自身の脳内の整理 ならびに 開発内 / 開発外のメンバーへの共有にも非常に有益と考えています。
ただし作成コストは一定かかってしまうので、機能をまたいで制御が必要な機能開発時においてのみ作成をするのが良いと考えています。
■ 今後の運用
機能をまたいで制御が必要な機能開発時において作成を原則必須としようと考えています。
作成コストが一定かかってしまうので、速度優先の場合やコアとなる要素でない場合には不要で良いと思います。
4-2-4. D: ドメインモデル図
※ 一部実際の成果物とは、表現を変えたり簡易的に記載している箇所があります。
■ sudoモデリング上の定義
簡易化したクラス図のようなもので、次のようなルールで記述した図
- オブジェクトの代表的な属性を書くが、メソッドは書かなくてよい
- 「ルール/制約(ドメイン知識)」を吹き出しに書き出す
- オブジェクト同士の関連を示す
- 多重度を定義する
- 集約の範囲を定義する
- 日本語と英語の対訳を定義する
■ どのような方針で作成したか
オブジェクト図を作成した後に、オブジェクト図をベースにして抽象化したうえでリレーションや用語を整理しています。
抽象化する過程でオブジェクト図の整理の仕方や要素の過不足がある場合には適宜オブジェクト図の修正もしながら作成をしました。
集約の範囲と英語の名称もここで明確に定義します。
■ 所感
個人的にはこの表で記載される内容はソース上で表現されれば良いのかなとも感じています。
ただし以下の点においてこの図は有用であると考えています。
- 現在の開発環境ではソースをもとに図示化する仕組みがなく、図示化され視覚的に認知しやすい情報に価値がある
- 図示化されたものがあると、レビューしやすく開発外メンバーへの説明時にも利用できる。
- 全体を俯瞰した上で要素や命名の洗練に注力できる
- オブジェクト図と対比しやすい構造となるため、考案しているモデルが妥当かどうかを考えるうえで脳のスイッチコストが低く、効率的に考えることができる
■ 今後の運用
1は本質的には仕組みで解決できる課題であると思っているので、設計者(またはチーム)の練度に応じて、図示化のコストと思考しやすさのメリットを天秤にかけて必要であれば実施する。が良いと思っています。
なれてきたら、実際の実装物と、ソースを元に生成された図をもとにチューニングしながら開発をすすめる…が良いのかなと思っています。
4-2-5. 総論
今まで特定の手法に則ってモデリングを実施したことがありませんでしが、 sudoモデリング は非常に取り組みやすかったです。
特に「オブジェクト図」はやってみた結果、想定以上に効果があり、共通認識醸成のために有用と感じました。 (具体例を例示したうえで構造を理解できるという観点で価値ありと感じています。)
5. おわり
まずは、長文となってしまった記事を読んでいただきありがとうございます。
(ここまで長文にするつもりはなかったのですが気づいたら..長くなってしまっていました..。)
5-1. まとめ
ビットキーのHome領域におけるドメインをベースに sudoモデリング を実践した経験をまとめました。
実際のモデリングに取り組む前に、現在のドメインの大枠を整理したうえで取り組むことで、比較的スムーズに取り組むことができたと思います。
システム図は低コストで実現可能で、QAやビジネスサイドの人間含めて大前提となる認識をあわせるうえで有用と判断しています。
ユースケース図は、現在の運用においてNotionをもちいたストーリー一覧と同等な立ち位置となるので不要と判断しています。
オブジェクト図は、一見複雑な物事に対して機能開発をする際に非常に有用で作成に一定コストを要しますが積極的に利用していきたいと判断しています。
ドメインモデル図は、ソースからUML図などの図を可視化する仕組みが整っている場合などにおいて有用性は低いかもしれませんが、練度が一定水準に満たないうちはモデルの妥当性を客観的にチェックする図として有用と判断しています。
5-2. 感想 / 学び
実際に本記事を記載するにあたって、すらすら記載することができず、つまづきながら言語を選びながら記載をしました。
まだ言語化の仕方が不適切な部分もあるとは思いますが、普段何気なく取り込んでいる開発で扱っているドメインを言語化する過程で学びも多くあり、まだまだ未熟な部分があったと感じることができました。
まだまだ「ドメインの理解」や「言語化」において精進していきたいと感じました。
5-3. 勧誘
ビットキーの事業内容に興味をもって、一緒によいプロダクトに洗練させていだける方！募集しています！
5-4. 余談
今ふりかってみて、事業の創業期からこのモデリングの仕組みないしはDDDをとりいれたほうが良かったか？という問いに関しては「NO」だと考えています。
homehubという概念が爆誕し、対象のビジネススコープが大きく変わったタイミングで仕組みを考え直す選択は考える価値があったと考えていますが、初期はどうしても速度が求めれらるのでこの仕組をそのまま取り入れられるかと言われると「難しい」「手続き型で実装したほうが価値をだせていた」と感じています。
「事業フェーズごとに最適な戦略は異なる」ということと、「ターニングポイントにおいていかに先んじて戦略を変える舵きりをすることの重要性」の2点を再度認識することができました。
5-5. 事業とドメインの変遷記事の宣伝
本記事のベースとなるドメイン知識について、事業の変遷と合わせてまとめたものを別記事で記載しています。ぜひそちらも合わせて参照ください。本記事に記載している内容がより具体的なイメージをもって理解できると思います。