Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by RepositoryRepositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository
Functional and Reactive Domain Modeling 各章まとめ - Qiita
Functional and Reactive Domain Modelingとは、ドメイン駆動設計(DDD)の関数型プログラミング(FP)とリアクティブプログラミング(RP)によるアプローチを書いた本 1. 関数型ドメインモデリング：イントロダクション 変更可能なステートを避ける - 変更可能なステートは管理が難しく、非決定性につながる 参照透過性 - FPは、参照透過なモデルコンポーネントを設計する能力を提供する。モデルの振る舞いが純粋関数で構築されていることで合成性を得られ、小さな関数から大きな関数を作ることができる 自律的成長 - 関数型の設計と思考で、モデルは自律的に成長する。純粋性故にモデルは数学的に扱うことができ、推論ができる コアドメインに集中する - DDDの原則を使用してモデルを構築すると、リポジトリやファクトリといったパターンに基づいて編成されたエンティティや値オブジ
ドメイン駆動設計の道標 - sandbox
この記事は 2016年 第2のドワンゴアドベントカレンダー、20日目の記事です。 qiita.com ドメイン駆動設計に関して悩める若者に送るポエムを書いていたら長くなりました。 20日目なはずなのに今日は 12/25 ですが、お察しください。 TL;DR ドメイン駆動設計には3つの顏がある それは「哲学」「戦略」「戦術」である 「戦術」にスポットがあたりがちだが、まず「哲学」とコアの「戦略」から理解する プロダクトにおけるドメインモデルの全体像を描いてから「戦術」を検討しよう ドメイン駆動設計をどの程度取り入れるかの 「ドメイン駆動設計の適用レベル」について はじめに ドメイン駆動設計(DDD)、以前と比較して認知が上がってきたのか、よく「DDD やってるんですか?」 「DDD ってどうはじめればいいんですか?」と聞かれることがあります。そしてこの時にまず話に上がるのが、エンティティ、集
ドメインとデータ、サブジェクトとオブジェクト、および、事実は常に事実であり、真実は常に仮説である、という話 - たなかこういちの開発ノート
先日参加の「PHPメンターズセミナー」には相当に触発されました。本記事はその勢いのままに書いたエントリーとなります。 ※下記記事もご参照ください。 →《PHPメンターズセミナーに参加してきました》 〜・〜 突然ですが、下図は、視点Aから見ると対象物は四角に見えて、視点Bから見ると三角に、視点Cから見ると円に見えるという様子を表したものです。一つの同一の対象物なのに視点によって見え方が異なる、という現象を説明するのによく使われるようです。 図１：四角、三角、円の三面図 例えば、渡辺幸三氏が下記記事にて、ご自身の「三要素分析法」を説明するのに用いています。『一つの開発対象システムだが、「データモデル」、「機能モデル」、「業務モデル」の三つの異なる視点、観点がある。各観点での設計をそれぞれ行って擦り合わせることで、対象システムの実体が浮かび上がる。』、、、このような趣旨の説明をされています。 I
[ 技術講座 ] Domain-Driven Designのエッセンス 第2回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第2回 DDDの基礎と実践 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 本連載は、全3回の予定でEric Evansの書籍『Domain-Driven Design』（以降DDD）を紹介しています。前回はDDDの概要を説明し、第I部「Putting the Domain Model to Work」からDDDの基本原則となる3つのパターンを紹介しました。今回は続く第II部と第III部から、（アンチパターンを1つ含む）16のDDDパタ
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
ユビキタス言語とドメインモデル、そしてモデル探求うずまき - じゅんいち☆かとうの技術日誌
最近、ドメイン駆動設計ってどうやって実践すればいいかなーという質問をよくされるので、この記事が満額回答にはならないと思いますが、書いてみたいと思います。 シンプルな問題はトランザクションスクリプト、いわゆる手続き型で対処できます。問題が小さいのでコードは直接的でわかりやすくなる傾向にあります。 とはいえ、世の中の問題はシンプルなものばかりじゃない。複雑な問題もある。DDDの著者であるEric氏は、複雑な問題はドメインモデルを使って対処すべきと説く。 ドメインとは問題の領域とか知識の範囲をいうのですが、DDDはそのドメインにある概念をモデル(ドメインモデル)として定義して、さらに実装として紐付けていく設計手法です。 モデルクラスは概念ありき 例えば、電車にまつわるドメインというので考えたとしたら 電車 乗客 駅 ダイア などの概念が登場します。 現実世界に限った話ではなく、仮想世界でもドメイ
Railsでサービスとフォームを導入してみる話 - assertInstanceOf('Engineer', $a_suenami)
この記事はRuby on Rails Advent Calendar 2013の6日目の記事です。 前日は @tkawa さんの「Favoriteの設計実装はパターンとして使える」でした。 Railsで適切に責務を分割するということ RailsはいわゆるMVCと呼ばれるアーキテクチャパターンにのっとったフレームワークであり、プロジェクトを作成するとデフォルトでmodels/、views/、controllers/などのディレクトリが作成されます。 基本的にロジックを記述する場所はモデルであり、ビューには表示処理だけを、コントローラにはアプリケーション上必要な手続きだけを記述するべきであると一般的には言われています。*1 ただ、それを忠実に実践していった結果、モデルが肥大化しメンテナンシビリティやテスタビリティが低下するという問題も多く指摘されています。 これについては4日目に @joker
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
似非サービスクラスの殺し方 / #ginzarb