なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
メモ:値オブジェクトの定義と差異について - かとじゅんの技術日誌
「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と
アプリケーションをドメインモデルで設計する - Qiita
親記事 : https://qiita.com/Regpon/items/1116679adadd8fb76f3f ドメインモデルで設計する狙い オブジェクト指向プログラミングにおいてかなり重要な内容となっているが如何せん概念的な内容となっている。ドメインモデルを設計するには幾度とない失敗の経験を重ねていき、常に改良していく精神が重要。そのための指針となる内容なので是非とも押さえておきたい。 それを踏まえてドメインモデルで設計する狙いは以下の通り。 業務的な判断・加工・計算のロジックを重複なく一元的に記述できる 業務の関心事(データ)とコードを直接対応させ、どこに何が書いてあるのかわかりやすく整理する 業務のルールの変更や追加の時に、変更の影響を狭い範囲に閉じ込める ドメインモデルの設計の難しさ ドメインモデルの設計は手続き型(スクリプト型)のプログラミングと比べて設計がむずかしいとされる
ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
