ドメインロジックはドメインオブジェクトに凝集させる - 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業界では「システム」や「ソフトウエア」といった言葉とくっついて頻繁に使われている。しかし、よく使われる言葉にもかかわらず、それが何かを明確に説明できる人は少ないと思う。 「アーキテクチャーとは、システムやソフトウエアの構造のこと」と説明を受けることがある（他にもいろいろな説明がなされるが、ここでは話を分かりやすくするため「構造」で説明されるケースに絞る）。 ここでいう構造とは、例えば「ハードウエアが何台あってそこにどんなミドルウエアが動いて何の役割を果たすのか」「アプリケ
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメインロジックの実装方法とドメイン駆動設計
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版