Scalaコードでわかった気になるDDD | GREE Engineering
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
ユビキタス言語とドメインモデル、そしてモデル探求うずまき - じゅんいち☆かとうの技術日誌
最近、ドメイン駆動設計ってどうやって実践すればいいかなーという質問をよくされるので、この記事が満額回答にはならないと思いますが、書いてみたいと思います。 シンプルな問題はトランザクションスクリプト、いわゆる手続き型で対処できます。問題が小さいのでコードは直接的でわかりやすくなる傾向にあります。 とはいえ、世の中の問題はシンプルなものばかりじゃない。複雑な問題もある。DDDの著者であるEric氏は、複雑な問題はドメインモデルを使って対処すべきと説く。 ドメインとは問題の領域とか知識の範囲をいうのですが、DDDはそのドメインにある概念をモデル(ドメインモデル)として定義して、さらに実装として紐付けていく設計手法です。 モデルクラスは概念ありき 例えば、電車にまつわるドメインというので考えたとしたら 電車 乗客 駅 ダイア などの概念が登場します。 現実世界に限った話ではなく、仮想世界でもドメイ
ドメインモデル - Strategic Choice
ビジネスロジックをオブジェクト指向で。どういうこと？ビジネスロジックにおいて、最も避けたい状況は、そのロジックが「複雑」になってしまうことです。とはいえ、現実のビジネスルールは多くのパターンを持ち、それを反映したロジックはとても複雑になりがちです。ドメインモデルは、この複雑性に「オブジェクト指向」をもって対応します。ドメインモデルは、対象となるビジネスエリアをモデル化したオブジェクトのレイヤを挿入します。ビジネスにおけるデータをモデル化するオブジェクトもあれば、ビジネスで使用するルールを扱うオブジェクトもあります。ドメインモデルは、データベースモデルと似ている場合もありますが、大きな違いもあります。ドメインモデルでは、データとプロセスが一体化され、複数値属性や複雑に絡み合う関係があり、さらに継承も使われています。どうすれば？シンプルなドメインモデルは、データベーステーブルごとに１つのドメイ
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメインモデル VS トランザクションスクリプト
