ドメイン駆動設計を実践するために - Digital Romanticism
ドメイン駆動設計の実践に向けて、DDD本では明示的に語られていない視点からドメイン駆動設計をとらえ直す。 導入 ドメイン駆動設計入門では、かなり抽象的なレベルでDDD本の根底にある思想を概観しました。一言で要約すれば「ドメインエキスパートの頭の中にあるドメインをとらえるモデルを共有し、オブジェクト指向のパラダイムを用いて、それをソフトウェアの実装に落とし込む」という構想であると言えるでしょう。これを踏まえて今回は、実践のためには何が必要なのか、という問題意識からドメイン駆動設計をとらえ直してみたいと思います。 今回のポイントはプロセスです。DDD本ではほのめかされているにすぎない「モデリングのために行われているもの」に焦点を合わせて、設計とプロセスをどのように融合させていけばよいのかを考えていきたいと思います。ここでの目的はDDD本を批判することではなく、語られない点からとらえ直すことで、
コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - かとじゅんの技術日誌
先日、DevLOVEで発表した「コードで学ぶドメイン駆動設計入門」ですが、入門としながらも難しかったかもしれません。モデリングの話は難しい方の話題なので仕方ないのですが、できるだけわかりやすく補足するブログを書いてみたいと思います。 まず、レイヤードアーキテクチャの話ですが、こちらのスライドを参照してください。 DEVLOVE HangarFlight で話したスライド&ソースコード - じゅんいち☆かとうの技術日誌 平たく言うと、そのアプリケーションが解決する問題の領域がドメインです。ドメインとそれ以外のものをごっちゃにしないようにしたのが、ドメイン駆動設計だと考えればよいと思います。 一般的に業務システムでは、対象業務がドメインに成り得ますので、ドメインは業務に準えて語られることが多いと思います。ドメインに登場する概念をユビキタス言語*1として定義し、モデルに落としこむというのが設計の
「ドメイン駆動設計」は新人SEの必修項目でいいと思う - flairDays - てさぐりの日々
珍しく日記が続いています 何をやらせても3日と続きやしない私がブログを3日連続で書いている時点で、空からヤリが降ってもおかしくないこの年度末、皆様いかがお過ごしでしょうか。 最近すっかり拙著ネタばっかりになってしまいましたが、急に「昨日はengine.ioいじって挫折してました」とか書いても話題が飛びすぎるので、書籍つながりでドメイン駆動設計(DDD)について個人的な意見を書いてみたいと思います。 ドメイン駆動設計(Domain Driven Design) 一部の方には釈迦に説法になってしまうかもしれませんが... ドメイン駆動設計（英: Domain-driven design, DDD）とはソフトウェアの設計手法であり、 '複雑なドメインの設計はモデルベースで行うべきであり'、 'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメイ
ドメイン駆動設計本の読書会に参加してきた - nyanp::blog
エリック・エヴァンスのDDD本、大阪で読書会が開催されているというので行ってきた。 【限定募集：第1回の申込者のみ、参加登録可能】第２回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper 勉強会はまだ1章途中、自分で読んだのもまだ4割くらいだけど、得るものが多い本＆勉強会だと思う(主催の@kuma_nanaさんありがとうございます)。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (132件) を見る ざっくりに言うと、ドメイン(ユーザーの問題領域)のことを深く考えてソフトウェア作っていきましょうと
ドメイン駆動設計読んだ - hitode909の日記
ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で，Kindleで買えたので読んだ．ドメインを軸に戦略的に設計しましょうという本．2週間くらいで読めて良い体験できてよかった． ソフトウェアを，ユーザーインタフェース，アプリケーション，ドメイン，インフラストラクチャという4つの層に分けて，一番重要なのがドメイン層で，ドメイン層にアプリケーションが存在し得る理由がある．銀行システムだったら，口座とか利子みたなやつがドメイン層で，口座がよくできてると銀行としてうまくいく．ATMのタッチパネルというのはユーザーインタフェースで，どんなにATM押しやすくても，ドメイン層に，口座という概念がなくて，ただのハッシュだったりすると，銀行を運営して金を儲けるとか，新たな金融商品とか作るのが困難になる．インフラ層は永続化とかするのだけど，インフラ層がいかによくても，意味ないデータを保存していては銀行倒
メソッド設計で守るべき10個のルール - A Day In The Life
以前メソッド設計の原則に関する記事を書きましたが 質問をすることで答えは変更されない原則 メソッドの引数はオペランドのみにする原則 それ以前にメソッド設計する上で最低限守った方がよいルールをまとめてみました。 プロパティをメソッドの戻り値代わりに使ってはいけない ファンクションメソッドでプロパティの値を変更してはいけない プロパティをリターンしない インスタンス変数やプロパティをメソッドの引数に渡さない 参照渡の引数をリターンしてはいけない 例外処理を GoTo 文の代わりに使ってはいけない 理由なく id 型をメソッドの戻り値にしない 特定メソッドの呼びだしが前提になったメソッドを作ってはいけない パブリックメソッドからパブリックメソッドを呼ばない プライベートメソッドからパブリックメソッドを呼ばない 以下その詳細です。 プロパティをメソッドの戻り値代わりに使ってはいけない メソッドが呼
実はオブジェクト指向ってしっくりきすぎるんです！ 不変オブジェクトのすゝめ。 - Bug Catharsis
バグのないソフトウェアを作りたいお仕事では主にVB.NETとC#を。趣味のプログラミングでは関数型言語F#を利用しています。 私自身のF#スキル(関数型的な考え方)は、まだまだ実践レベルとはとても言えないシロモノだけど、 面白い発見と多くの可能性を感じられる言語なので、F#はさわっていてとても楽しい。 私はこれまでオブジェクト指向言語によるオブジェクト指向プログラミングをこよなく愛してきました。 というのも、「いかにバグを減らすか」、「バグのないソフトウェアを作ること」が私の最大の関心事だからです。 バグの多いコード、あるいは技術的負債の多いコードというのは、コスト的な問題があるばかりか、 開発者の身体や心までもを不健康にし、われわれに大きな不幸をもたらすことを経験的にわかっているからです。 わたしにとってオブジェクト指向技術は、それらの問題を防いだり解決をする手段として適した技術でした。
MVCのモデルのあり方について考えた - 130単位
deeekiモデルとかエンティティとかDAOとかDTOとかの自分の中での定義付けをはっきりさせときたい ( 2010-04-03 16:48:21 ) 既存Webアプリのコードを踏襲しながら新規開発、なんてことをしています。そこで立ち止まったのが、MVCアーキテクチャのモデルについて。モデルという言葉の定義が難しいですが、RDBMSを利用する場合テーブル毎に対応するもので、ロジックを主に記述するものという捉え方でいます。そのモデルですが、ざっくりと「データアクセスロジック」と「データそのもの」に分けられると思います。 既存コードでは、データアクセスとデータそのものが一つのクラス/オブジェクトでまかなわれていました。つまり、自身でテーブルのカラムに対応したプロパティを持ち、自身にupdateやらdeleteやらのメソッドを持つというものです。 この構造になんとなく違和感を持ったまま開発をして
手続き型に改宗しました - 純粋関数型雑記帳
つい先日にあのような資料をアップロードして心苦しいのですが、手続き型に改宗することにしました。誰よりも関数型言語を愛し、常日頃よりどうして関数型が流行らないのかを考え続けていた私ですが、10年余りを経てようやく気付きました。関数型がイケてないから流行らないのだと。 関数型の人たちは言います。immutableこそ正義であると。でもそうなんでしょうか？変数に代入できる方が書きやすいに決まっています。書きにくいと思いつつも、Haskellというのは曰く、素晴らしい言語なのだから、そんなことはないはずだと自分をごまかしごまかしこれまで生きてきましたが、そうじゃないんです。ようやく目が覚めました。変数に代入できる方が書きやすいのは当たり前なんです。 モナドなんてへんてこなものを当たり前のように持ち出さなければならない時点でおかしいことに気付くべきでした。なぜ私はコンソールから文字を入力したいだけな
コードのクリーンアップ - 技術的負債の返済に役立つ 9 つの戦術
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 技術的負債の返済に役立つ 9 つの戦術 David Laribee MSDN Magazine の 2009 年 12 月号では、技術的負債に取り組むために、問題を特定して主張を展開するためのアドバイスを書きました。簡単に言えば、近い将来に問題になりそうな負債を特定することが重要だと信じています。コードベースのほとんど触れられない部分で、価値ある技術を確立しても、明日の生産性向上の実現には役立ちません。 また、負債返済の重要性について経営陣からお墨付きを得ることの重要性を理解し、同じ理由から手堅い主張を展開するための基本ツールを用意してください。 では、利息の高い技術的負債を返済するうえで役立つ可能性がある戦
依存関係逆転の原則（DIP） - Strategic Choice
依存関係逆転の原則（DIP:the Dependency Inversion Principle）上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。どういうこと？手続き型は「方針」が実装の「詳細」に依存する構造になってしまう。 方針が詳細の変更に影響されてしまう好ましくない構造。 OOプログラミングでは「方針」「詳細」とも抽象に依存させることで、悪しき依存関係を逆転できる。 なんで？アプリケーションの方針を決めていて、他に対して影響を与えるモジュール(＝言うなれば「偉い」ヒト)は上位。 上位が下位に依存してしまうと、上位が、下位の影響を受けてしまう。手続き型でよく見られた悪い依存関係。 筋的にはアプリケーションの存在理由である上位が下位に対して影響力を持つ
DDDについて、だらだらと - みねこあ
ちょっと体調を崩しまして、病院にいってきたのですが（インフルエンザではない）、待ち時間が半端ないのはわかっていたので、Domain-Driven Design (DDD)を持って行きました。 Domain-Driven Design: Tackling Complexity in the Heart of Software 作者: Eric Evans出版社/メーカー: Addison-Wesley Professional発売日: 2003/08/22メディア: ハードカバー購入: 4人 クリック: 113回この商品を含むブログ (89件) を見る MVC のネタを書いたときに、梅澤さんに WebのMVCですが、Domain-Driven Designの言葉で語れば混乱は生じないと思うんですよね。 とコメントを頂いたのですが、DDDが積読状態なので「そうですよね〜」と言えないわたしは、あ
[tech]GUI-MVCとWeb-MVCの違い - yojikのlog
一部でMVC議論が流行っていたので、自分のためにSmalltalk由来のMVC(以下、一般化してGUI-MVCと呼びます)はWeb-MVCとどう違うか? という点についてまとめて見ました。突っ込みは歓迎。 あと本稿ではドメインモデル貧血症批判とかは全く盛り込まない。それは少し違うレイヤーの話なんです。 0. VCは大抵の場合、緊密に結びついたペアである GUI-MVCではView-Controller(以下VCペア)は不可分のペアだとされています。情報の入力(および制御)と出力ですから、お互い強く依存するのはあたりまえですね。MicrosoftのMFCとかJavaのSwingではVCはひとつのコンポーネントとして扱っています(Document-Viewパターンとも呼ばれます) ただ、この点についてはWeb-MVCでもそんなに変わらないかも。 1. GUI-MVCのView-Controll
![[tech]GUI-MVCとWeb-MVCの違い - yojikのlog](https://cdn-ak-scissors.b.st-hatena.com/image/square/b01b0c66c2194b2606fbb5505652ff3db80d0cdf/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729901763%2F12704830469097198255%2F1365590825)
その３ 拡張できて修正不要の原則 ： OCP
ホーム < ゲームつくろー！ < オブジェクト指向設計編 < 拡張できて修正不要の原則 ： OCP その３ 拡張できて修正不要の原則 ： OCP オブジェクト指向には幾つか「原則」と呼ばれるものが存在しています。原則（Principle）というのは約束(Promise)や指針（Guideline）よりもはるかに強い戒めです。オブジェクト指向における原則は、よっぽどの理由が無い限り破る事は許されないものばかりです。沢山ある原則の中で、ここではオブジェクト指向の基本原則である「Open-Closed Principle : OCP」について見ていくことにします。尚、今回の話は「まさーるのページ」（石井様作成）にあるオブジェクト指向に関する素晴らしいお話の影響を多大に受けております。このページをご覧になりますと、オブジェクト指向の本が読みたいと熱望してしまうこと間違いなしです。私も思わず関連本を
モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:
MVCの話もっとしてほしい - ✘╹◡╹✘
昨日バイト先で男子しか参加しない女子会して、開発の仕方どうするかみたいな話合いしたの面白かった。 押し付け合い回避のためにもレイヤ 趣味や価値観をリアルタイムで押し付け合うのはギスギスして良くないが、話し合うべきときを設けてやはり定期的に話し合うべきだと思った。コード内のインターフェースが少ないと、そういう押し付け合いが起こる可能性が多く出てきたり、それを避けるために心理的に間違った方向に実装しそうで良くない。データAPIが薄くてコントローラに書くことが増えると、コントローラ内で押し付け合いやすいみたいなそういう。レイヤ分けて「はい俺バリア〜ここからさき俺の実装〜〜」みたいなのが良さそう。 MVC界隈の知識源 MVC関係の話、まとまった情報源が無くて、Togetterかブログエントリあたりで適当にまとめられていることが多い。PoEAA(Patterns of Enterprise Appl
いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経
今さらなのだけれども、「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」を読んだ。仕事で活用できるかと問われると微妙だけれども読んで良かった。避けていたのはいろいろな誤解があった。複雑なソフトウェアを作る為の考え方。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者:エリック・エヴァンス発売日: 2011/04/09メディア: 大型本 Eric EvansがDDDのアイデアを著書のドラフトというかたちでWeb上で公開し始めた2002年以来、この知恵の書は多くの識者の間で話題の中心となり、「徹頭徹尾有用な書籍（most thoroughly useful book）」とまで評された。記述されている内容の一言一句すべてにおいて役に立つことしか書かれていない、と賞賛
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
20110409_DevLOVE「実践！ ドメイン駆動設計」_増田亨さん
ドメインロジックの実装方法とドメイン駆動設計
MVCの先、状態管理、ジェスチャー
