ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab

この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性

[t-wada]

"テストとDDDは切っても切り離せません" "テストがなければモデルとコードを改善していくことができない" "#TDDBC の @t_wada さんの基調講演観賞会を行った" こう活用してもらえると、動画公開して本当によかったと思います

[n0dam1]

UseCase が他の UseCase 呼ばないの、どうやって強制させるかが知りたい

[rin51]

「1クラス1パブリックメソッド」クラスが乱立しそうだけど

[qtamaki]

インスタンス変数を持たなければ分割する必要もインスタンス化する必要も無いのに

[eller]

独自ルールの強制には https://www.archunit.org/ という手もありますよ。

[dekasasaki]

DDDへの真摯な取り組みは、仮に失敗しても、他の誰よりも高度な抽象化のスキルを手に入れられるから応援します。実はかなり潰しが効くスキルだと思う。

[efcl]

"「重要な原則を何度も繰り返すこと」「義務感ではなく、必要性を感じて取り組んでもらうこと」" テストと責務の一般的な話の後にモデル図の有用性を得る話

[iekusup]

ほー。

[j5ik2o]

設計改善の治具としてのテスト重要。他にもDDDとTDDの関連は"意図の明白なインタフェース"にある。TDDのように利用者の視点で設計を考え"意図の明白なインタフェース"を目指すことでモジュール性を高めることができる

[k-holy]

なんとかServiceみたいなクラスを廃止して、ユースケースに紐付いたクラスを1つに絞るのが肝なんだろう。各ユースケースに共通する処理は独立させる。業務仕様をWikiじゃなくモデル図に集約するの、めっちゃ良さそう。

[objectiveworker]

データ構造が動的に変わる問題を扱わない限りデータモデルで十分だと思うけど。ただのCRUDアプリをORマッパーを使ってオブジェクトモデルとして扱っているの？

[n314]

気になる

[tenkoma]

早速Slack絵文字作った

[xlc]

mochaにおいてTDDとDDDは関数名の違いに過ぎないんだけどね。

[nunulk]

"大切にしていることは「重要な原則を何度も繰り返すこと」「義務感ではなく、必要性を感じて取り組んでもらうこと」です。"

[syukit]

熱意がすごい　かっこいいなー

[yufufufu]

開発の参考にする

[jmatsu]

わかりが深すぎた

[nakag0711]

共用されているプライベートメソッドは下のレイヤに括り出すという意味？それしたら別に1クラス1パブリックメソッドでなくても相当薄いレイヤになってそうだけど

[tune]

UseCaseの使い方よさそう。モックの苦しさも経験したことがあるので納得感が高い

[littlewat]

具体的で実践できそう