コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - じゅんいち☆かとうの技術日誌 からの連投エントリ。振る舞いとサービス編です。今回もコードを使って解説したいと思います。 サービスとは、モノとして扱うと不自然なものをサービスに分類しようという考えです。 ドメインで扱う概念の中には、1つの機能や処理が単体で存在していて、もの（オブジェクト）として扱うのが不自然なものもある。そうしたものは、サービスという形でユビキタス言語に組み込む。サービスは基本的に状態をもたない（stateless）。 佐藤さんが語られている通りに、従来のサービスとDDDのサービスはレイヤーの位置関係が違います。今までのサービスはDDDのアプリケーション層です。このエントリでは、今までのサービス(DDDのアプリケーション層)の話は一切出てこないので、今までのサービスの概念を一旦忘れましょうｗそう
Martin Fowler の PofEAA や Eric Evans の Domain-Driven Design に登場する “サービス” と呼ばれるものたちについて整理し、然るべきタイミングで活用したいというモチベーションで調べた内容。
最近DDDやDCIなどのキーワードが気になっているのですが、そんな折に下記のような勉強会が開かれるのを知ったので参加してみました。 10月26日 豆ナイト：ドメイン居酒屋～モデル駆動プログラミングの集い～(東京都) DDDやDCIが気になっているのは、「Railsで “skinny controller, fat model” を意識して書くとモデルにメソッドが集まりまくる」のをなんとかしたいなと思っていて、その解決方法としてDDDやDCIが有効なのではないかと考えているからです。 内容的には、最初に発表された増田さんのスモールオブジェクトプログラミングの話がとても響きました。このスライドで書かれているアンチパターン「ひとつの部品(クラス)がいろいろ知っていて、なんでもやりたがる」ってまさにRailsのmodelなんじゃないのかなあ。 ちいさなオブジェクトでドメインモデルを組み立てる fr
This is a sample application (Todo list) of a Rails application with a clear separating of layers, while still supporting Active Record pattern usage. I believe it’s very important for a mature product and system to clearly communicate is intent on a layered architecture, being a no-brainer for a new developer to the project. We all know that Rails is about doing things fast, but we must learn to
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）は、「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
