大失敗した設計、そしてドメイン駆動設計の基本に立ち返る – 福地春喜のブログ

※ 2019年7月27日に追記しました。 この記事の最後に、失敗談の補足を書いた記事へのリンクを追加しました。 システムの一部機能を改修するテーマが現在進行中です。テーマは他の箇所に影響がないくらいに分離できるものです。この大きさが丁度いい。チャンスとばかりにリファクタリングすることにしました。 アプリケーションはそれなりにレイヤー化されています。controllerとserviceとrepositoryがある。よくある３層構造です。何を見直して再設計するのか？それはドメインオブジェクトモデルの構築です。 現状のアプリケーションはビジネスロジックをモデリングしたものとは言えない状態です。自分がやったのだけれど。しかしだからでもあります。なぜこうなったかを振り返り、どのようにできたかを考えます。失敗から学べることもあるはずです。 参照側の層は薄く？本当に？ 開発対象のシステムはある情報の検索

[mather314]

何が問題だったかを分析することはとても大事です。

[hi-hats]

ちょくちょく流れてくるタイトルみて「面白そうー」と思ってた記事をやっと読むと、あれなんか聞き覚えが。。 と一番下まで行くとふくちさんの顔出てきた。泣ける話。

[efcl]

Repositoryで複雑なロジックを持ってしまったFat Reposiotry、Value Objectが機能してなかったケース

[vanbraam]

ここで言う"DTO"がAnemic Domain Model b:id:entry:4665662398847577058(のobject)と同じものなのか,"値オブジェクト"が Value Object b:id:entry:4671971116547882082と同じものを指すのかに興味を感じる

[RabbitBit]

自身の失敗を振り返ってブログ記事として共有するのは、なかなかできる事ではないと思う。

[ilyaletre]

コンポーネントをレイヤ化するところは所与の語彙があるのでそれを助けにパターンの適用ができる。けど、自分のドメインは自分で語彙を抽出しなきゃいけないので設計が後手になるとか？（ブーメラン）

[atty]

失敗の共有はいいね

[rryu]

必要なのは値オブジェクトではなくビューモデルな感じがする。ビューの入出力も複雑になってくるとモデルとして具現化しないときつくなってくるが、それができないとどこかに間借りしている存在になってしまう。

[h_taiji]

うちもファットレポジトリなりがち。今は諦めてるが、そのうちこうゆう活動をしなきゃいけないなーと思っては、いる

[masuda220]

こういう現場での経験や取り組みを言葉にする活動は、多くの学びを生む。読む人にとっても貴重な実体験の参考情報だし、書いた人も、書くことで学びが深くなる。

[katzchang]

基本は「ドメインモデルが素直に実装されてるか」だと思うんだよね。実装パターンで語らない状態にしたい。

[bufferings]

DAOだけにするならクエリ用のDBを別で作って、メインのDBからデータを変換してそのクエリ用DBに投入する部分に業務ロジックが存在しそう。かなぁ。