DDDへのきっかけはフレームワーク選定だった

公開日:2019-07-06
最終更新:2019-07-10

プロジェクトへの参画が開発フェーズであった為、最初の仕事がフレームワークの選定でした。我々のチームが属するIT部門がPHPを得意としていた為、PHPでやるということは決定していました。

他のプロジェクトで Laravel の実績があったので、Laravel でやることが半ば決まっていたのですが、今後のシステム像現在の課題から、今一度熟考して見ることにしました。

フレームワーク選定の前提事項として決めること

フレームワーク選考にあたって、まずは以下の3点を決める事にしました。

  • システム構成
  • アプリケーション形態
  • 設計・開発手法

システム構成

  • モノリス(巨大な一枚岩)
  • コンテキスト分割(業務単位に適切にシステム分割、サブシステム的な単位をイメージ)
  • マイクロサービス(サービス単位に小さく分割)

システムを分割すればするほど、API連携などが増えるため、フルスタックフレームワークからAPIさえ実装できればよい軽量フレームワークへと重点が変わると考えました。

アプリケーション形態

  • 従来型 Web アプリ(UI をサーバーサードでレンダリング)
  • SPA + API(フロントエンドとバックエンドを分割)

こちらも SPA + API とするならば、APIが実装しやすいフレームワークが求められると考えました。

設計・開発手法

  • データ中心アプローチ(DAO, 画面設計、DB設計、CRUD)
  • ドメイン駆動設計(DDD, 業務領域にフォーカス、モデリング、不変条件)

DDDとなった場合はDDDでの開発に向いているフレームワークを選択する必要があると考えました。

現在の課題を考えるに、明らかに従来のやり方を改善する必要がありました。今こそDDDじゃないのか?ここで、はじめてDDDと言うキーワードが大きく心を捉えてきました。

...DDD ...DDD ...DDD

前提事項検討の結果

  • システム構成 → コンテキスト分割
  • アプリケーション形態 → SPA + API(ただし条件付き)
  • 設計・開発手法 → ドメイン駆動設計(ただし条件付き)

検討の結果、上記の方向性で決まりました。

システム構成に関してはマイクロサービスほど細分化はしないが、DDDで言うところのコンテキスト分割はやろうというところに落ち着きました。具体的には2コンテキストに分割することになりました。

SPA + API と ドメイン駆動設計についてはまだよく知らないので評価・検証フェーズ(小さめの実験)を経て最終決定することとなりました。

次のアクション:評価・検証フェーズ

  • SPA + API:フレームワークを仮選定し、簡単な実装をしてみて評価する
  • ドメイン駆動設計:1機能をドメイン駆動でモデリングしてみてプロセスやドキュメントをレビューして評価する

この段階ではコンセプトは理解しても具体的なイメージが湧いていないという状態なので、丁寧に説明して共通認識や理解を得て行く必要がありました。実際、自分も実はDDDはやったことが無く、ネットや書籍の情報を語っている状態だったので、段階的にレベルアップしていく必要がありました。

ここから、DDDへの挑戦と猛勉強がはじまる...

記事が少しでもいいなと思ったらクラップを送ってみよう!
0
+1
DDDやアジャイルに挑戦する記録

よく一緒に読まれている記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる

技術ブログをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

技術ブログを開設する

Qrunchでアウトプットをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

Markdownで書ける

ログ機能でアウトプットを加速

デザインのカスタマイズが可能

技術ブログ開設

ここから先はアカウント(ブログ)開設が必要です

英数字4文字以上
.qrunch.io
英数字6文字以上
ログインする