「ドメイン駆動設計」の複雑さに立ち向かう
13. オブジェクト指向の「変更容易性」 (どのパラダイムでも同じだけど） • 抽象データ型／段階的な抽象化 – プログラムを人間の発想に近づけると扱いやすい • モジュラープログラミング – 独立性の高い部品に分けると扱いやすい – 関連するデータと操作は、ひとつのプログラミング単位に • メッセージング – 部品の組合せを柔軟に変更できると扱いやすい – sender/receiver/dynamic routing – Javaだとうまく実現できていないアイデア • メッセージングの考え方の参考 • Erlang, EIP:Enterprise Integration Patterns, マイクロ サービス, …
java-ja.ddd の資料、ブログ記事などのまとめ
matome.md 概要 この資料は、java-ja.ddd の資料、ブログのまとめです http://connpass.com/event/1934/ 資料 和智さんの発表資料 http://www.slideshare.net/digitalsoul0124/ddd-17678116 増田さんの発表資料 http://www.slideshare.net/masuda220/ddd-forname ブログ http://erukiti.hatenablog.com/entry/2013/03/23/162949 http://d.hatena.ne.jp/kaz_shu/20130323/1364030804 http://starzero.hatenablog.com/entry/2013/03/23/232532 http://heartbeatheart.blogspot.jp/
java-ja.DDD にいってきました
元気です。 はてなブログに移しました。 http://heartbeatheart.hatenablog.com java-ja.DDD に参加して来ました。 会場を提供してくれた GREE さんすごい。ビールとピザとオードブルごちそうさまでした。 補欠で参加登録したけど、繰り上がりで参加できた。 正直、「エリック・エヴァンスのドメイン駆動設計」 を買ったがパラパラとめくっただけでまだ全文を読んだとは言えない状態な自分。 今回、参加して DDD とはどういうことか自分なりにまとめると ソフトウェアが複雑なのではない。複雑なユーザーの行動・ビジネス要件をシンプルに定義できないから複雑なソフトウェアになる。 データ構造も重要だが、ユーザーがどのようにシステムを触るかという観点(ストーリー)に沿ってモデルを考えてみる モデルに対して機能を付与したり組み合わせる。処理をそのモデルに任せる。 汎用的
リッチなドメインモデル 名前探し
3. ドメイン駆動設計への道 設計の改善 ドメインの理解 ・メソッドの構成 オブジェクト指向 ・オブジェクト間の特性移動 設計のスタイル 言葉の力 基礎訓練 ・データの再編成 モデル駆動 ・条件記述の単純化 責任駆動設計 エクササイズ ・メソッド呼び出しの単純化 役割ステレオタイプ ９つのルール 小さく作る 責任割当の原則 GRASP For 実装の原則 Thoughtful Developer ・クラス Leading Designer ・振る舞いとメソッド ・状態とコレクション 契約による設計 4. ドメイン駆動設計への道 シンプルな ﾄﾗﾝｻﾞｸｼｮﾝｽｸﾘﾌﾟﾄ リッチな 大きな ﾄﾗﾝｻﾞｸｼｮﾝ 泥団子 ｽｸﾘﾌﾟﾄ リッチな シンプルな ドメインモデル ドメインモデル アーキテクチャなし 汎用データ型 テーブルと対応した 業務の言葉で組み立てる 汎用命名ルール ドメインオブジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
