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