杉本 啓「2つのドメインモデル―DDDの含意」
Kei Sugimoto, “Two Domain Models - An Implication of DDD”, PHP Mentors, (December 20, 2015) ドメイン駆動設計（Domain-Driven Design: DDD）は、オブジェクト指向、デザインパターン、リファクタリングなど、ソフトウェア設計分野における幅広い知的遺産と交差します。それゆえ、ドメイン駆動設計は、ドメイン指向のアプリケーションソフトウェア開発に馴染むような仕方でこれらの知識資産を統合したものと見ることができます。 こうした見方は妥当でかつ生産的でもありますが、DDDの業績に対しては別の見方もあり得ます。それがこの短い論考のテーマです。 この文脈において、DDDは、「ソフトウェア設計」から、私たちが特別な思い入れを込めて「情報設計」と呼ぶものへの静かな出発として考えることができるかもし
コマンドとクエリ分離原則 - Strategic Choice
コマンドとクエリ分離原則ファンクションは抽象的な副作用をもたらしてはならない。どういうこと？コマンド オブジェクトを修正するために使われる。プロシージャとして実現される。クエリオブジェクトに関する情報を返すために使われる。フィールドとして確保されるか、ファンクションとして実現される。ファンクションについて、クエリに答えるというファンクションの公の目的を超えてオブジェクトを変更（＝副作用）してはならない。どうすれば？メソッドをコマンドかクエリかのどちからに分類し、コメントにもどちらなのかを明記する。クエリに分類されたメソッドは、オブジェクトの状態を絶対に変えない。効果メソッドをコマンドと捉えると、Tell, Don't Ask（求めるな、命じよ）という考え方を強く意識できる。クエリから副作用がなくなれば、ユニットテストもしやすくなる。コマンドとクエリの分類を意識すれば、そのデータを外部から見
副作用を最小限に抑えるために必要なこと - かとじゅんの技術日誌
若干、難しい話ですが、設計力を上げたいプログラマ向けなエントリ。私も道半ばです。一緒に考えていただければ幸いです。 堅牢なアプリケーションを実現する上で「副作用を最小限に抑える」という設計思想は、非常に重要な示唆を含んでいます。 その「副作用」とは、そもそもどんな定義なのでしょうか。 DDDでは"side effect"と定義していて、以下のように解説されています。 Domain-Driven Design: Tackling Complexity in the Heart of Software: Evans, Eric: 8601300201665: Amazon.com: Books エリック・エヴァンスのドメイン駆動設計 作者:Eric Evans翔泳社Amazon P250より引用 In standard English, the term side effect implies
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
