DDD失敗談を話して学んだこと関西Javaエンジニアの会(関ジャバ) '17 10月度 - connpass https://kanjava.connpass.com/event/68169/ での発表資料です。
DDD Alliance! ドメイン駆動設計のためのオブジェクト指向入門に参加してきた - はむはむエンジニアぶろぐ
2016年1月21日に開催されたドメイン駆動設計のためのオブジェクト指向入門に参加してきました。 その時のスライドがこちら ドメイン駆動設計のためのオブジェクト指向入門 from 増田 亨 www.slideshare.net 発表内容のメモを残しておく 私のDDDに対する解釈が、混じったメモになります。 DDDは、インクリメンタルな設計である。 ドメインに対する理解(ベース)をもとに、オブジェクト指向で表現する。 ドメインモデルとは、ドメインの知識を鋭く解説する。 ドキュメントで、長ったらしく解説するより語彙が大事。 モデルと実装は結びつけろ。 開発の生産性 変更容易性 が、もたらされる。 日常で使われる言葉をコードで体現する。 ドメインを分析する人と実装する人が別れてはいけない。 ドメインを分析する人がコードを書き、コードを書く人が、ドメインを分析する。 クラスを作るためには、分析が必
「DDD パターンを活用した Laravel アプリケーション開発」を Laravel Osaka 2016 で発表しました。 - Shin x Blog
2016/10/19 に大阪で開催された Laravel Osaka 2016 にて、「DDD パターンを活用した Laravel アプリケーション開発」を発表しました。 会場の MOTEX さん。巨大スクリーンが 2 面あり、話しやすい環境でした。 発表資料 Laravel の具体的なテクニックに比べると抽象的な内容なので、どれだけ伝えられるか思案したのですが、聞いて頂いた方からのフィードバックや参加者アンケートでも概ね良い評価を頂けたので安心しました。 ValueObject については、さらに掘り下げて話せるテーマなので、これ単体でもまた話してみたいです。 Value Object は基本ですね | DDDパターンを活用した Laravelアプリケーション開発/ddd-with-laravel https://t.co/ZzRTnt0tY6— 増田 亨． (@masuda220) O
ドメイン駆動で開発する ラフスケッチから実装まで
4. 拙い設計 • コードが重複しまくっている • 条件分岐の密林があちこちにある • どこに何が書いてあるかわからない • 変更した時にどこで何が起きるか推測できない • やっていることは解読できるが、なぜ、そこでそ の処理が必要か意味がわからない • パッケージ名/クラス名/メソッド名/変数名/コメン トが嘘だらけ • でも動いてる 動いていなければ、ろくでもない設計であることは誰でもわかるのに… 4 5. 善い設計 • コードの重複がなくなる • 条件分岐の密林がなくなる • どこに何が書いてあるかわかりやすくなる • 変更した時に影響範囲を限定しやすくなる • 処理の意図がすぐわかる • パッケージ名/クラス名/メソッド名/変数名が わかりやすく正確になる – コメントはむしろノイズ 5 ドメイン駆動設計を実践すると、自然にこうなっていく
ドメイン駆動設計の学習曲線とブレークポイント
15. ９つのルール 1. 一つのメソッドでインデントは一段階 2. else 句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 15 16. 名前をつける 1. 一つのメソッドでインデントは一段階 2. else 句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 16 パッ
InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
PHPカンファレス2015 PHPメンターズセミナー「モデルを設計せよ！―ドメイン駆動設計を超えて」参加レポート
2015年10月03日にPHPカンファレンス2015内で、ミニカンファレンスとして開催されたPHPメンターズセミナー「モデルを設計せよ！―ドメイン駆動設計を超えて」に参加してきました。 モデルを設計せよ！―ドメイン駆動設計を超えて視点PHPメンターズ 後藤秀宣 @hidenorigoto セッションのテーマは「視点」。いくつかの実例から、参加者が視点そのものについて実際に考えることができる体験的な講演でした。後藤さんのスライドに関しては公開は無しとのことです。このセミナーでは、この「視点」という言葉が全体を通じてのテーマになっていると思います。 特に印象深いのが「コップを空にする」話です。既にたくさんの知識を身につけた修行僧が、高名な僧侶のもとに学びに行きます。修行僧がひとしきり知識を披露した後、高名な僧侶は空の茶碗にお茶をそそぎ、そそぎ続けて、茶碗からお茶が溢れてしまってもそれをとめませ
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
「これって、ドメイン駆動設計？」という資料を公開しました。 - GoTheDistance
いくら人の話を聞いてもピンと来ないし、DDD本を読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。 これって、ドメイン駆動設計？ from Michitaka Yumoto www.slideshare.net ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。 ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。 その世界で現状行われていること 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい) 上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが１つ。 で、ドメイン(特にいまやってる物事)を抽象化す
@kawakawaさんの「C＃実装から見るDDD」資料が素晴らしい #dddosaka - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経
今さらなのだけれども、「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」を読んだ。仕事で活用できるかと問われると微妙だけれども読んで良かった。避けていたのはいろいろな誤解があった。複雑なソフトウェアを作る為の考え方。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者:エリック・エヴァンス発売日: 2011/04/09メディア: 大型本 Eric EvansがDDDのアイデアを著書のドラフトというかたちでWeb上で公開し始めた2002年以来、この知恵の書は多くの識者の間で話題の中心となり、「徹頭徹尾有用な書籍（most thoroughly useful book）」とまで評された。記述されている内容の一言一句すべてにおいて役に立つことしか書かれていない、と賞賛
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
普段使いのDDD
IDDD本から理解するドメイン駆動設計一覧