ドメインロジックはドメインオブジェクトに凝集させる - Qiita
こんにちは。 最近、こんなツイートしたのですが、ドメインオブジェクトではなくアプリケーションサービス1などにドメインロジックが書かれてしまうことがあります。 アプリケーションサービスはドメインロジックを配置する場所ではない、それはドメインオブジェクトの役割。アプリケーションサービスは進行役。ここを間違うから簡単にドメインモデル貧血症になってしまうんだと思います。 — かとじゅん (@j5ik2o) August 18, 2019 最近、以下の書籍(以下 増田本)をマジメに読み直しました(笑)。ドメインモデル貧血症2を回避して、ドメインロジックをドメインオブジェクトに凝集させる方法に関して、増田本にいろいろ書いてあったので、そのエッセンスと僕の考察を交えて解説したいと思います3。 詳しい内容は以下の増田本を読んでください！ コード例はScalaですが難しい表現がないので、Scalaが分からな
FizzBuzzを題材にユースケース層についてを考えるのはおそらく無意味な気がする - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
やんざむ先生のこのツイートを見て考えたことをまとめます。 UseCase がわからない... FizzBuzz で 「3の倍数のときは fizz が返る」 「5の倍数のときは buzz が返る」 「3の倍数かつ5の倍数のときは fizzbuzz が返る」 「3の倍数でも5の倍数でもないときはそのままの数字が返る」 これは— Yuki Anzai (@yanzm) February 15, 2019 結論を先に書くと、「これはそもそも問い自体が不適切である」（しかし強いて言えばEntity）という立場をわたしは取ります。以下、まじめにFizzBuzzを設計しながら考えてみます。 ひとまず、出発点は上にあるツイートの疑問から出発するとしましょう。 まず前提として、ユースケースってどういう役割か まず前提として、ぼくはユースケースを「ドメインモデル（このツイートで言うところのEntity）やイン
開発者が知っておくべきSOLIDの原則 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています（頭字語はMichael Feathereによって名付けられま
アーキテクチャーとは「エンジニアの発想」のこと | 日経 xTECH（クロステック）
情報システムの良しあしはアーキテクチャーで決まる――。よく言われることだが、これは正しいのだろうか？正しいとは思うが、どうもふに落ちない。たぶん「アーキテクチャー」が何を指すのかが明確ではないからだと思う。 アーキテクチャーという言葉を聞いたことのないITエンジニアはいないだろう。IT業界だけで使われる言葉ではないが、IT業界では「システム」や「ソフトウエア」といった言葉とくっついて頻繁に使われている。しかし、よく使われる言葉にもかかわらず、それが何かを明確に説明できる人は少ないと思う。 「アーキテクチャーとは、システムやソフトウエアの構造のこと」と説明を受けることがある（他にもいろいろな説明がなされるが、ここでは話を分かりやすくするため「構造」で説明されるケースに絞る）。 ここでいう構造とは、例えば「ハードウエアが何台あってそこにどんなミドルウエアが動いて何の役割を果たすのか」「アプリケ
System Requirements Specifications
システム要求仕様書の書き方 IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specificationより Table of Contents (目次) 1. Introduction (はじめに) SRSの「はじめに」では、SRS全体の概要を書く。 1.1. Purpose (目的) この小節では SRSの目的を描写する SRSが意図する聴衆を指定する 1.2. Scope (範囲) この小節では これから作るソフトウェア成果物に名前を付ける このソフトウェア成果物が何であるか(必要ならば、何でないか)を説明する 指定されたソフトウェアの適用について、対応する利点、目的、目標を含めて記述する もし上位レベルの仕様書(例えばSyRS)があれば、同様の記述と矛盾がないようにする 1.3. Def
システム設計 設計の考え方
要件定義、基本設計、詳細設計、プログラム設計、テスト、運用というシステム構築の手順が一般的に浸透しているが、このプロセスは 実践ではほとんど守られておらず、要件定義の中で、ユーザと一緒に一部分を掘り下げて行っているうちに混合されることが多い。 ここではその区別について考える。ただし、実践手順が多少、イレギュラーに設計されるのは全体の合理化を促進しようとするためであり、必ずしも良くないこととは言い切れない。 基本的には必要とされるアクターを考えることが重要だと思われる。 外部設計（システム設計） ＝システム方式設計+ソフトウェア設計 内部設計 ＝コンポーネント設計 詳細設計 ＝プログラム設計 （IPA） １．システム方式の決定：アーキテクチャーとして、H/
谷島の眼〜ソフト開発に仕様書は必要？不要？ - ニュース - nikkei BPnet
今回は、「ソフト開発に仕様書は必要か否か」について考えてみたい。4月13日に公開した「本当の中村修二・幕引きの弁」に対する読者コメントの中で、このテーマが登場した。プログラマをされている読者と、ユーザー企業の情報システム部門におられる読者の間で、ちょっとした議論が起きた。 もともとの記事は日経ビズテック編集長の仲森が執筆し、主題は技術者の処遇であった。この記事から派生した「ソフト開発を巡る仕様決定や文書化」というテーマもまた重要であり、筆者もそれに関して記事をあれこれ書いてきた。本来ならITProなどIT関連サイトで議論した方がよいテーマであるが、ことの経緯から本欄で取り上げることにする。 まず一連の読者の書き込みを再掲する。文章の一部を筆者が編集・修正した。編集長の仲森の記事が公開されて後、31歳のプログラマの方がこう書かれた。 ■（前略）それになにより、無駄な仕様書作成やらくだらない社
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
Seasar S2Tiger - @//メモ
app.dicon † <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE components PUBLIC "-//SEASAR//DTD S2Container//EN" "http://www.seasar.org/dtd/components.dtd"> <components> <include path="dao.dicon"/> <!-- DAOs --> <component name="CustomerDao" class="com.snail.exam.s2dao.CustomerDao"> <aspect>dao.interceptor</aspect> </component> <component name="OrderDao" class="com.snail.exam.s2dao.OrderDao"> <aspe
鈴村さんが指南する業務フロー図の上手な書き方
まずは，業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが（図1）である。スイムレーンに役割を書き，上から下（または左から右）に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し，矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り，業務とは複雑なものである。厳密に書こうとすると，業務フローも複雑になりがちである。しかし，分かりやすさを重視するなら，一つの業務フローに登場するアクティビティはせいぜい10～15程度にとどめるべきだ。 複雑なフローを表現したければ，一部の業務フローを別に切り出して，サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が，サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」
基本設計の基礎
技術や製品の多様化，不十分な要件定義の増加，オフショア開発の進展などにより，基本設計の難易度がますます上がっている。一方で開発の現場では，新規開発案件において十分に時間をかけて基本設計を実施するケースのような，ITエンジニアが基本設計のスキルを磨くチャンスが減っている。そうした要因により，ITエンジニアの基本設計のスキル不足が叫ばれることも珍しくない。 そこでここでは，基本設計の基礎を解説する。Part1では，基本設計を取り巻く環境の変化を改めて示したうえで，基本設計とは何か，ITエンジニアが身に付けるべく基本設計のスキルとは何かを提示する。Part2とPart3ではそれぞれ，DOA（データ中心型アプローチ）とオブジェクト指向による基本設計の基本を解説する。さらにPart4では基本設計で用いるパターンを，Part5では基本設計フェーズのドキュメントのレビュー方法をそれぞれ取り上げる。 Pa
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
MVC - MVCとはModel-View-Controllerの頭文字をとったものです。
MVC - MVCとはModel-View-Controllerの頭文字をとったものです。 目次 新着情報2004 MVC関連リンク MVCと３層C/S 関連モデル PAC - Presentation - Abstraction - Controller Document - View architecture MVC発祥の地では 雑談 MVCとはModel-View-Controllerの頭文字をとったものです。 新着情報2004 月刊DBマガジン6月号にModel2+の解説があるらしい。（ニュースソース[jfriends-ml 11123] Model2+） MVC関連リンク MVCモデルという言葉をよく聞きますが何のことですか？ http://www.atmarkit.co.jp/fjava/javafaq/j2ee/j2e07.html 使わないと損をするModel-View
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメインロジックの実装方法とドメイン駆動設計
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版