0063 号 巻頭言
DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という
![新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/da075520c5346bf5227bf90557a35ccf8b5b07ae/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20181210%2F20181210195849.png)
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
[ Android ] - これからの「設計」の話をしよう | Recruit Tech Blog
はじめまして。 6/1より入社いたしましたAndroidエンジニアの釘宮です。よろしくお願いいたします。 今日はAndroidの設計について語ってみようと思います。 その前に 「良い設計とはなにか」という議論が「正義とはなにか」という議論のようにいつまでたっても結論がでないのは、環境やチームメンバのスキルセット、ステークホルダーによって目指すべきゴールが変わるためだと考えます。 つまるところ、設計に正解はありません。 そのため以下で話すことは、「これが設計の正解だ！！」というわけではなくて、「こういう設計の仕方するとうまくいくっぽい」くらいのノリです。 あと、特にMVCとかDDDとか人によって解釈のズレが起きやすいところなどは、冗長になるのを嫌って自分の解釈で言い切っています。ご了承ください。 設計の目的について ハードルが下がったところで、早速。 まず設計の目的ってなんでしょうか？ この
![[ Android ] - これからの「設計」の話をしよう | Recruit Tech Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/a2437e1635f82304e06624b7c640608b0941d92d/height=288;version=1;width=512/https%3A%2F%2Ftechblog.recruit.co.jp%2Fassets%2Frmp%2Fthumbnail%2F5222.jpg)
長年、邦訳されなかった「思慮深いソフトウェア開発者全員の必携書」
「Domain-Driven Design」通称「DDD」の原著が出版されたのは、2003年のことだった。Kent Beck氏が賛辞に寄せた「思慮深いソフトウェア開発者全員の必携書」という言葉が示している通り、英語圏では圧倒的な支持を集め、出版から7年が経過した現在でも、Yahoo! Groupsのメーリングリストでは活発な議論が交わされている。 一方、日本では少し状況が異なる。識者の間では、有用な書籍として早くから知られていたものの、500ページ超という厚さと、文体の難しさが、多くの日本人エンジニアの挑戦を阻んできた（邦訳も待ち望まれたが、長い間出版されなかった）。 佐藤匡剛氏による「Domain-Driven Designのエッセンス」、徳武聡氏による「DDD Quickly 日本語版」をはじめ、日本語の情報は少なからず存在したし、国内での実践事例も徐々に蓄積されていたものの、本質的に
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
