tezu memo blog

日々行った作業をメモしていきます

Software Design 2023年2月号 ドメイン駆動設計入門 を読んだ

gihyo.jp

自身のドメイン駆動設計の理解や状況

感想

  • DDDの目的(事業の変化とともに成長と進化を続ける)を意識していなかった p19
    実務では、アジャイルな開発・テスト自動化・CICDパイプラインで成長と変化に対応している
    DDDはソフトウェアアーキテクチャとして使用しているが、この視点は欠けていた
  • 業務とプログラムのトレーサビリティを確保 p23
    業務知識・モデル・プログラムのトレーサビリティを確保しないと、事業の変化にシステムが追いつかないですよね・・
    普段から後続のフェーズを意識した成果物を作成しているので、これは大丈夫
  • 「複雑な業務ロジックに焦点を合わせる」のドメイン駆動設計の開発のやり方 p27
    • 複雑な業務ロジックが少ないシステムで全ての処理にDDDを適用!となると、フルスタックフレームワークの長所を消してしまう短所の方が上回るので注意が必要
    • 複数のレイヤーで構成。かつ、各レイヤー間の値を受け渡しにDTOを使っていた設計を見直しした記憶が蘇ってきました
  • 業務ルールからエンティティ・値・コレクション・区分オブジェクトを抽出する方法が纏まっていてとても参考になる p35-40
    • 特に業務の概要からエンティティを見つける点に関しては、業務知識とモデルのトレーサビリティ確保の点でとても重要
    • 実務ではECサイトの注文番号を値オブジェクトにして、Eloquent:ミューテタ/キャスト 8.x Laravel で取り出せるようにしていました
  • SIer時代、システムのリニューアル時は現地で現行システムの具体的な運用(画面操作して頂くなど)を見せて頂きたいと依頼してました。見学は良いですね p53
  • WBSで予めリファクタリングのタスクを入れるのは自分も難しいと感じた。機能開発時に要リファクタリングみたいなTODOコメントを残して、これらが溜まったらリファクタリングしているので、予めスケジューリングするのは難しい p59

まとめ

「複雑な業務ロジック」を対象していることが理解出来たのが良かった

業務知識・モデル・プログラムのトレーサビリティが最も重要だと感じたので、これらのサンプルがあれば嬉しかった