実際に新規開発する際とか既存システムのリプレイスで導入した経験はない状態です。「ドメイン駆動設計を導入するためにやったこと」という勉強会に参加してきました。勉強会での内容を気になったポイントに絞ってまとめ、僕の解釈や感想も書いてみました。今まで僕が参加した回の現場から学ぶモデル駆動設計の勉強会での学びや気付きなどについてまとめ記事を作ってみました。「ソフトウェアの機能性を高める」ことと「ソフトウェアの保守性を高める」ことである。何かしらの課題を解決するためにソフトウェアを作るのに、エンジニアだけで妄想しても本当に役に立つものはできない。課題に詳しい人たちと一緒になって課題領域のモデリングを行うことで機能性を高めることにつながり、そのモデリング結果をソースコードにマッピングしながら落とし込む+ドメイン駆動設計のプラクティス(値オブジェクトなど)を使うことでさらにソフトウェアの保守性を高めることにもつながるんだ。いうのが僕の解釈です。ユーザ業務を徹底的に理解する姿勢、テストコードを書かないと気持ち悪い・モデリングがタスクの最初に入るという文化になった。実際にペアプログラミングだったりモデリングを一緒にやったりすることで文化が変わっていったそうです。新機能リリースの際はEA(一部ユーザに先行して機能開放)とGA(全ユーザに機能開放)を行いフィードバックをもらいながら機能追加開発を進める。僕が今後担当する自社プロダクトにおいてもこの考え方は応用してみたいと思いました。結局1社目導入の際、そこまでお客さんが求めておらず、かなりコストかけて作ったものの、機能を落としたものがいくつもありました。思っていたのですが、まずは最低限の機能でリリースしたり、早い段階で実際に先に触ってもらって、フィードバックをもらいながらシステム開発を進められる仕組みを作れればこのような事態にはならなかっただろうなと。巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例(ミノ駆動さん)問題領域と課題領域を整理してコアドメインを見つける。機能追加等していく方針にしているそうです。巨大レガシーシステムに無限にコストをかけるわけにはいかないため、コアドメインになる部分のみ既存アーキテクチャを変更してDDDを導入し、そのほかについてはリソースを割かないようにしている。巨大レガシーシステムのコアドメインを整理するまでの有識者探しが、ミノ駆動さんが転職したばかりかつコロナの影響でリモートワークのため大変だったそうです。何年もかけてごちゃごちゃになった巨大レガシーシステムのコアドメインを整理するのもめちゃくちゃ大変なのでしょうが、、、MEMO問題領域と課題領域について問題領域は解決しようとしている領域のこと、で課題領域はどのようにその問題を解決するのかということ。別々の問題領域なのに、それを1つの課題領域としてシステム化したりするとカオス、、、、プロダクションコードを用いたデザインパターン適用を通じて開発メンバーへ設計の重要性を浸透させていく。設計の重要性をチームに浸透させていったそうです。設計の議論が活発になっていっているそうです。(この活動は、是非参考にさせて頂こうと思いました。同じようなロジックが至るところで書かれていたものがキュッとなったそうです。insert)画面、機能毎に分割してカチッと決めていくのではなく、全体としてこういう要素が必要で枠組みとしてはこうだけど、個々の要素はなんでもいい(先送りにできる)という考え方の切り替えを行い、開発を進められたそうです。機能性を向上させるために、どんな人をどう巻き込んでどう整理するのが効率いいのか??整理したものをどう開発につなげる(マッピング)、どんなテストを書くのが保守性を高めたり品質向上につながるのか??を意識して開発を進めることが大事なのだと改めて思いました。同じ目線で議論できる何かしらの資料(できれば開発まで落とし込めるやつ)を用意して、定期的に議論できる場をセットする。そんなところから実践できたらなぁと思います。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。