Value Objectについて整理しよう - Software Transactional Memo
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
あなたの遅延はどこから？ SQLから！ 〜患部に止まってすぐ効くSQLレビューチェックリスト 年初め特大サービス号〜 - ANDPAD Tech Blog
あけましておめでとうございます！ 今年は異世界放浪メシのアニメが放送されるらしいので楽しみなバックエンドの原田 (tomtwinkle)です。 内部で運用しているSQLレビューチェックリストの一部を抽出し思いつきで追記して行った結果、結構な分量になってしまいました。 暇な時でも流し読みして頂けるとありがたいです。 Motivation SQLレビュー観点 大きくSQLが変更される修正の際にはEXPLAINをレビュー内容に加える 検索のキーにINDEXを使用しているか SQL発行回数がN+1(1+N)の構造になっていないか サブクエリを利用したSQLはパフォーマンス要チェック Viewの利用は基本的に禁止 CROSS JOINは禁止 WHERE句で十分に絞った検索をしているか 必要なcolumnだけSELECTしているか レコード数だけ必要な場合にCOUNT用のSQLを発行しているか 集計関
Rails の問題は Rails のベストプラクティスがフロントエンドのベストプラクティスの邪魔になるどころか全く逆方向で相反してる点です。DHHの思想がフロントエンドと根本的に逆行してる。そういう人が作るフレームワークなのでwebpackerの抽象化を根本的に間違ったりする。 — prev.js (@mizchi) December 1, 2020 昨日もリプライで少し書いたけど、DHH自体が直近のHeyの開発でも明確にJavaScriptというものを触れないようにすることを是としているような主張をしているので、DHH wayが色濃く反映される以上この状態はもう避けられない気がしている — potato4d / Takuma HANATANI (@potato4d) December 1, 2020 Railsがフロントエンドの最先端をゆく人々1から良く思われないのは事実として。 Vie
設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ！！！— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ
ドメイン駆動設計の正体
はじめに "ドメイン駆動設計は当たり前のことを言っているだけ" "ドメイン駆動設計はただのオブジェクト指向プログラミング" "ドメイン駆動設計はより良いアーキテクチャだ" "軽量DDDはアンチパターンだ" このようなドメイン駆動設計に関する言及を聞いたことがあるでしょうか？ ドメイン駆動設計に言及する記事や書籍は多くありますが、それぞれ着目する側面が異なったり色々なコンテキストから言及されています。 おそらくそれが原因でドメイン駆動設計が何であるかをぼやけさせ、正体のわかりにくい概念になっているように思えます。 そこで今回は色々な観点から整理し、ドメイン駆動設計とは何であるのか、その正体を考えていきます。 ドメイン駆動設計の基本的概念について ドメイン駆動設計はEric Evansが出版した「Domain-Driven Design」という書籍がルーツになっています。 ドメイン駆動設計を一
【第1回・前編】 エンジニア和田卓人の今を形作る技術 | GeeklyMedia(ギークリーメディア) | Geekly（ギークリー） IT・Web・ゲーム業界専門の人材紹介会社
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD（Domain-Driven Design）を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め
初めに きっかけ 新人研修中にDDDとか、PoEAAとかの話が少しだけ出ました。 ただ、イマイチわからないとの声が多数。 理由 なぜなら予備知識がたくさん必要だからです。(ほんとに多い) これはわからなくて当然。 そこで 独断と偏見で、予備知識となる用語を解説します。 偏見多いので、より正確な情報は、書籍やWebで調べてね。 この辺を説明します UML クラス図/シーケンス図 デザインパータン GoF/PoEAA 階層化アーキテクチャ DDD本のサマリ 知らなきゃいけない知識が多くて面倒だね。 説明しないけど、オブジェクト指向やデータベースとかの知識も必要だよ。 説明前にDDD本のページを見てみよう！！！ DDD本の最初のページ 「エリック・エヴァンスのドメイン駆動設計」より ??? よくわからないね さっきの図って何? 灰色の中心部分はソフトウェア設計のモデリングを表しています。 モデリ
POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた
『Sustainable Web Development with Ruby on Rails』はRails使ってるなら絶対面白いと思う
『Sustainable Web Development with Ruby on Rails』はRails使ってるなら絶対面白いと思う David Bryant Copelandの『Sustainable Web Development with Ruby on Rails』を読んでいますが、この本めちゃめちゃ面白いですね。 Railsの設計で悩んだことのある人なら絶対読んで損はないというか、共感したり反発したりにやにやしたりで楽しめると思います。RailsというかWebアプリ開発の歴戦の勇士（正直あまり若くなく、つらい経験を重ねてきた生き残り的な人）が語るベストプラクティス感があります。 本書の構成 大きく3部構成です。 Introduction その名の通り導入です。本書の目的、Railsのアーキテクチャの紹介と、ビジネスロジックの話など。 「Sustainable」とは何か？ とい
2022年上半期に読んだ技術書
2022年上半期はとある都合もあってかなりの数の技術書を読んだので、その中でも良かったものとかの感想をまとめておきます。 2022年上半期で一番良かった技術書 A Philosophy of Software Design ソフトウェア設計の目的は複雑さを軽減することであるとして、その複雑さの定義と軽減する手法が書かれています。最近まで2年ほどフリーランスで色んな会社の開発に参加して、DDD的な設計やクリーンアーキテクチャを採用している現場が多かったもののそれらが逆に開発効率を低くしているのではという感想を持っていました。そこでこの本を読み、それらの目的であるはずの「複雑さを軽減する」という視点が抜けていたのかなと気付かされました。コードを読み書きしていて複雑さを感じなければモノリスでもMVCでもいいケースは多いと思います。複雑さを軽減する手法を解説する章では、やりすぎると逆効果であるとは
Value Objectが盛り上がっているらしい。 Value Objectについて整理しよう - Software Transactional Memo Value Objectの説明に異論がないものの、主題はValue Object Obsessionのほうですよね。 こちらも聞いてみた。 fukabori.fm よい機会なので、よくわかっているつもりの、値オブジェクトというかドメイン固有型について再考してみよう。 それは値か属性か それはエンティティの全メンバーやデータベースの全列のために「顧客郵便番号」「送付先郵便番号」「事業所郵便番号」「契約日」などのクラス(メンバではなくクラス！)を定義して、immutableな振る舞いを強制する事を以てValue Objectであると言い張り、ドメイン知識の断片をそれぞれのクラスに書き散らして「高凝集になった」「型システムが守ってくれる」と喜
PoEAA を通して DDD の半分を理解する マーティン・ファウラーの PoEAA を読んでから、DDD のことを考え続けている。今まで DDD の話題はあえて避けてきた。分厚く難解な書籍、増えるコード量、教祖とその信徒たち（MV）、全てをその視点から解釈しようとする試み、少しでも間違えたら求められる自己批判、無知な者に対する SNS 上のオルグ、いつまでも出てこない総括、それでも信じるものは救われる。「一匹の亡霊がIT界隈を徘徊してる。DDDという亡霊が...」 まあ早まらないでほしい。何も DDD こき下ろそうというわけではない。自分の実力不足が主な原因と思い、深入りする前から「わからないもの」と決めつけていた DDD は、PoEAA というライトに照らされてその姿を私の前に姿を表し始めた。それは亡霊ではなく、確固たる手触りのある実体（Entity）だったのである。 PoEAA は
最近、ドメイン駆動設計(以下DDD)とかそのあたりを読みこんでいる人から、DDD本の読み方を教えてもらいました。ここではDDD本はエリック・エヴァンスのドメイン駆動設計の方を参照しました。 @katzchang さんから教わったのは「DDDはパターンランゲージの形式を意識してるよ」ということでした。ただし、きちんとしたパターンランゲージの形式になっておらず、記述が著者のものになってるので、読者は注意して読む必要があるのかもとのことです。 @ryoaitaさんから教わったのは「DDDはエンタープライズアプリケーションアーキテクチャパターン(以下PofEAA)を下敷きにしている本だよ」ということでした。 DDDももう時代的にはかなり古い本です。自分で読んだ限りは全然好きになれなくて、でもきっと何かあるはずだと3-4冊読んでみましたが感想は変わらずでした。ユビキタス言語も「当たり前のものを先頭に
「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と
モノリスからマイクロサービスへ-ZOZOBASEを支える発送システムリプレイスの取り組み - ZOZO TECH BLOG
はじめに こんにちは。基幹システム本部・物流開発部の岡本です。普段はZOZO基幹システムのリプレイスを担当しています。 ZOZOではさらなる成長のため、様々なリプレイスプロジェクトが進行しており、これまでにZOZOTOWNやWEARなどのプロダクトにおける多くのリプレイス事例を公開してきました。本記事では、2022年8月より本格始動したZOZO基幹システムリプレイスの第一弾であるZOZOの物流拠点「ZOZOBASE」を支える「発送システムリプレイス」を紹介します。「発送システムリプレイス」は設計を終えた開発段階で、リリースに向けて進行中です。本記事を皮切りに今後も継続的に発信を続けていくので、是非ご注目ください。 現状の「発送システム」は、Classic ASPのトランザクションスクリプトで実装された大規模なモノリス構成のシステムの一部であり、「障害リスク」と「開発速度の低下」に課題を抱え
「写経」の原典 - きしだのHatena
書籍とかのサンプルコードをそのまま入力して勉強することを「写経」というけども、それを言い出したのは角谷さん、というメモ。 写経は言葉ではなく心で理解するのが大事。 2004-2005頃に @t_wada と働いていた頃、サンプルコードをコピペでなく手打ちすることを「写経」と呼んでました。和田さんが以前の現場に通いながら"TDD by Example"のサンプルコードを「祈るような気持ち」で手打ちしていたというエピソードを形容して「写経ですね」と呼んだのが始まりだったような…— Kakutani Shintaro (@kakutani) 2021年9月18日 恐らく2005年7月ごろではないかと思われる。 この夏は写経が来るね, 地震が来た - 角谷HTML化計画(2005-07-23) 角谷さんのブログでの初出も7/15だけど、babieさんのコメントを見るとこの時期にまわりで語ってたこと
Re: ドメイン固有型(値オブジェクト含む)を再考する - Software Transactional Memo
blog.j5ik2o.me 値オブジェクトはドメイン固有型の一種です。なので、不変と等価判定だけではなく、なにかしらのドメイン固有の不変条件(invariant)を維持する責任があると考えます(もちろん型として切り出すわけですからその投資に見合うだけの見返りがないといけません)。 違う。値オブジェクトとはID以外で等価判定をするオブジェクトの事であって、RubyのHash、Pythonのdict、C++のstd::unordered_setすらも値によって等価判定を行うのでこれらは値オブジェクトであるがドメイン固有型ではない。RubyでHashに入れて渡されたユーザ入力値をValidationしてドメイン固有型に詰め直すのはもちろん必要ならやれば良いが、Hashクラスそのものにモンキーパッチなり特異クラスなりを行って不変条件を維持する責任を負った自分専用Hashを作って普通のHashクラ
先日、 という記事を書いたところ、思ったよりも反響がありました。その影響があったかは不明ですが、また値オブジェクトについての話題がちょびちょびと発生していました。 そのやり取りの中で、私は未読だった論文が紹介されていて、その論文を読んだことで「このようにすると値オブジェクトに誤解が生じる」という一つのストーリーを認知できたため、どのようにこの論文を読むと誤解が発生するか、という事について説明します。 なお、前回書いた記事も、この記事も、誤りを糾弾したいとか、誤ったから著者が悪であるといった事を主張しているわけではありませんので、改めて記しておきます。この記事では、単純に事実の指摘と修正の提案、およびなぜ文脈や定義を大事にする必要があるのかという事について述べます。 いい加減、値オブジェクトの話題はしつこすぎるのでは？非生産的なのでは？そんな事よりもっと生産的な事をしたら？というご意見もある
モジュラモノリスで表現する複雑なドメイン領域と境界 https://speakerdeck.com/showmant/expressing-complex-domain-regions-and-boundaries-with-modular-monoliths PofEAAで考えるSaaSバックエンドの作り方 https://speakerdeck.com/dnskimo/pofeaadekao-erusaasbatukuendofalsezuo-rifang The Clean Architecture https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html Freer Monads, More Extensible Effects http://okmij.org/ftp/Haskell/
年の瀬ご多端の折、皆様におかれましては本年も大変お世話になりました。crowdworks.jpの開発をしているプロダクト開発部部長兼VPoEの@hihats です。 本記事はクラウドワークスAdvent Calendar 2022 24日目の記事です。 我々の組織ではこれまでも技術的負債解消に取り組んできていましたが、今期（10月）よりさらに人と時間をそこに集中しています。これまでこのブログでも紹介されてきたようにRuby on Railsのモノリスとなっているcrowdworks.jpにおいて、フロントエンドのVue.jsへの移行は今年に入ってから着々と進む中、バックエンドのほうは保守性の低下からどう脱却していくかが手付かずに近い状態でした。 この本丸を攻略するにあたって、闇雲にリファクタリングしていくぞ！では到底うまくいきそうにない。まず「何故やるのか、何をゴールとするのか」の意識あわ
#yapcjapan YAPC::Kyoto 2023に行ってきた・喋ってきた - その手の平は尻もつかめるさ
yapcjapan.org 2023年3月19日に開催されたYAPC::Kyoto 2023に参加してきました。もう2週間も前の話になるんですね......USに戻ってきてから色々あり、すっかりブログを書くのが遅くなってしまいました。 YAPC::Kyotoの様々な感想については「にゃんこ酒場.fm」で id:papix、id:karupanerura さんら運営の方々と喋ったPodcastが公開されているので是非お聴きくださいませ！ nyanco-sakaba-fm.hatenablog.com 面白かったトーク ジョブキューシステムFireworqのアーキテクチャ設計と運用時のベストプラクティス id:tarao さんの発表。Fireworqが発表されたあたりって、スケーラビリティが高くなおかつ複数の言語から良い感じで使えるジョブキューのプロダクトについて「何使えば良いんだろうねえ」っ
Rubyとの出会い、Railsの衝撃、Rubyコミュニティの面白さ【Rubyistめぐりvol.1 takahashimさん】 - STORES Product Blog
Rubyist Hotlinksにインスパイアされて始まったイベント『Rubyistめぐり』。第1回は高橋征義さんをゲストに迎えて、お話を聞きました。 パーソナルコンピュータとの出会い 藤村：こんばんは、藤村と申します。STORES のCTOをやっています。Rubyist Hotlinksをプログラミングを始めた頃にめっちゃ読んでて。 高橋：あれいいですよね。 藤村：いい。プログラマがどういう人たちなのか、なんとなくわかるみたいな、めっちゃ好きなコンテンツだったんですよ。で、ある日、これをもっとやった方がいいと思ったので、弊社でもやってみようとなったのがこのRubyistめぐりですね。ということで第一回は高橋会長に来ていただきました。なぜかというと、この STORES を手伝ってくださっているからというところでございます。 高橋：その話はあんまり外でしてないので、あらかじめお話しておきます
翔泳社さんのセールが8/20までだそうなのですが、某所に書いた「定番ぽいやつ（紙で買ってるけどPDFもついでに買っておくと良いかも的な）リスト」をこちらにもかんたんな説明をつけて書いておきます。 なお、この「定番ぽい」というのは、何年も前から良い本として広くおすすめされてきた本や、これから末永くおすすめされそうな本、ということです。一般に書籍の評価は、賞味期限の長短やターゲットの広さ・狭さとは異なるので、別に広くおすすめされない本でもいい本はありますし、将来はさておき今なら必読、という本もあるわけです。が、それらを並べはじめるときりがないので、ここではそういった本はここでは触れません。 そういう縛りがなければ、例えばカイゼン・ジャーニーシリーズ（という言い方でいいのかな？）やルビィのぼうけんシリーズや技術者の数学書シリーズとかもあるわけで、各自探してみるとよいかと思います。 一方、もっとニ
｢YAPC::Kyoto 2023｣にはてなのエンジニアが4名登壇します - Hatena Developer Blog
こんにちは, Webアプリケーションエンジニアの id:papix です. 最近気になっているPerlの新機能は新しいclass機能です. さて, 2020年に開催予定だったものの, 新型コロナウイルス感染症の影響で延期となったYAPC::Kyoto 2020が, YAPC::Kyoto 2023としてRebootし, 2023年3月19日(日曜日)に開催されることになりました! yapcjapan.org ｢try/catch｣をテーマにするこのカンファレンスに, はてなはパールスポンサー + トートバックスポンサー/学生旅費支援スポンサーとしてスポンサーをさせていただくことになりました. 加えて, はてなからは3人のエンジニアがYAPC::Kyoto 2023に登壇することになりました. 残念ながらチケットは売り切れてしまっていますが, 当日は発表の模様をYouTubeにて配信する予定
株式会社ビープラウドが主催するIT勉強会「BPStudy」。#151となる今回は、設計の代表格であるオブジェクト指向、モデリング、そして設計にフォーカスをあて、LT大会を開催しました。株式会社ミライトデザインのCEOでもある林宏勝氏は、「DDD時代に考えたいICONIXプロセス」というタイトルで、DDDを使っていて難しいと言われている戦略設計や、効率的に動かす方法などを語りました。講演資料はこちら 戦略設計と戦術設計 林宏勝氏：今回「DDD時代に考えたいICONIXプロセス」というタイトルで発表します、林です。 今日話すことは、Today's Topic ICONIX in the DDD era。DDDのモデリングをするにあたってICONIXをどう生かしていくか「DDDをやりたいけど、ICONIXは何に使うの？」みたいな話ができたらと思います。時間の都合上、ICONIXの詳細なやり方は、
みなさんもそろそろ牛丼に飽きて、海鮮丼が食べたくなった頃だろうか？ もらえるかはわからないけれどアンサーソングを待たずに、個人的なメモだと書いてある記事に言及するのは無粋かもしれない。しかし、どうしても気になってしまい見過ごせない記述があったのでこれを書くことにした。 気になったのは Learning Domain-Driven Design のバリューオブジェクトについての要約部分についてだ。 かとじゅんさんは同書の Chapter 6. Tackling Complex Business Logic をもとに、次のような感想を書いている。 値オブジェクトは振る舞いとデータを含むドメインモデル(ドメインオブジェクト)である、と示されている まず気になるのが、ドメインモデルとドメインオブジェクトが同一であるかのような記述だ。しかし、ドメインオブジェクト(Domain Object) という
【感想】『Clean Architecture 達人に学ぶソフトウェアの構造と設計』：クリーンなアーキテクチャの探求＋至高のドーナツ＋豊富な昔話 - Rのつく財団入り口
「アーキテクチャのルールはどれも同じである！(ドヤっ)」 数々の書籍やアジャイルソフトウェア開発宣言、SOLID原則の提唱などで業界では有名なアンクル・ボブ(Uncle Bob)ことロバート・C・マーチンさんによる、よりよいソフトウェア・アーキテクチャと設計の追求の本。原著が2017年、翻訳が2018/8、その後ITエンジニア界隈でもかなり話題になりました。 実は去年一度読み始めたのですが、AWS認定を突破する！と決意したので例のタマネギ(あるいはドーナツ)にたどり着く前に中断。無事に３冠突破して戻ってきたので、今年の夏に改めてじっくりと最初から読むことができました。 アーキテクチャのルールはどれも同じである！という帯の煽りは極端ですが、要はコンピュータやエンジニアリングの進化の中で発見されてきた、時代を超えて通用する不変のルールもある、これらをアーキテクチャの観点から見ていこうという本で
ファウラーのエンタープライズアプリケーションアーキテクチャパターン(PofEAA)において、 ビジネスロジックのアーキテクチャにはドメインモデルかトランザクションスクリプトかという二択があります。 仮にプレイヤーの名前変更(ゲームでは可能なことも普通にあるので)をするとします。 ドメインモデル var user = _repository.Find(userId); user.ChangeName(name); //バリデーションは中で行われる=ビジネスロジックがオブジェクトにある _repository.Save(user); ドメインモデル貧血症 //ロジックがモデルオブジェクトの外にある if(!IsValidName(name)) { throw new ArgumentException("name"); } var user = _repository.Find(userId)
【感想】『マイクロサービスパターン 実践的システムデザインのためのコード解説』：前編 - Rのつく財団入り口
「未来はすでにここにある。まだむらなく流通していないだけだ」←グッとくる 最初のエモワードがSF作家ウィリアム・ギブスンの引用でイイ！ サイバーパンク2077遊んでみた～い……じゃなかった、CloudFoundry.comのファウンダーでありMicroservices.ioの運営者、経験豊富なソフトウェアアーキテクトであるクリス・リチャードソンさんによる『Microservices Patterns』の翻訳本。 タイトルのようにアーキテクチャパターンやデザインパターンのようにマイクロサービスをパターンで体系化し、サンプルストーリーを元にした事例やコード例、OSS紹介を交えつつマイクロサービスを実践する設計方法を探求した本となっています。 Java文化圏で長く活動してきた方とのことでサンプルコードはほぼJava、Springフレームワーク、ご本人らによるマイクロサービス用のフレームワークEv
YAPC::Kyoto 2023 に参加してきました。 数年ぶりに参加したオフラインイベントで、おもしろ発表をいろいろ聞けたり、いろんな人に会えたりで、たいへん楽しかったです! 会場は3歩あるけばひさしぶりの人に会える空間となっていて、ずっと同窓会じゃん〜って言っていました。みなさまお元気そうでなにより。 発表では自分は id:onk さんの ORM - Object-relational mapping がおもしろかったです。データベースのアプリケーション上での抽象化は、長年どうするのがベストなのかというところを、ある意味職人的な感覚で捉えがちだったのですが、PofEAAの文脈で言語化していただいたことで議論可能になっており、すばらしーとなりました。 自分は最近はもっぱら ActiveRecord パターン界で生きていますが、たびたび考える必要のある領域なのでありがたいです。資料も期待。
こんにちは、大平(@yohira_dev)です。 2018年10月から3年間、業務委託としてグロービスの決済プラットフォームの改善に着手してきました。 本記事では2018年~2021年末までの「グロービスの決済システムがどう変化してきたか」「発生する技術的負債をどう改善してきたか」を赤裸々に解説していきたいと思います。 プロダクトの位置づけグロービスは主に、"社会人に必要なビジネススキルを動画で学べるサービス"「GLOBIS 学び放題」とその海外版である「GLOBIS Unlimited」を展開しています。 この二つのサービスの共通決済基盤を、近年のビジネス状況の変化に追従できる速度をキープしながら安定して運用することがグロービスの決済チームのミッションです。 ジョイン当初の状況さて、当初の決済基盤は大体こんな感じでした。 オフショア外注と開発した決済システム CIでRSpecが走っていな
Railsにおけるドメイン駆動設計の実践
「RailsでDDDをするのは難しい」とよく言われるが、こういう方法もあるというのを提示する。 ある程度のRailsの経験、エヴァンス本とPofEAAを十分に理解していること、ソフトウェアアーキテクトとして弁えるべきことを弁えていればこのページに書かれていることは納得いただけると思う。 DDDを実践するということ本題に入る前に断りを入れておきたいが、DDDをするということは要求分析やモデリングをきちんと行うということを意味する。「ドメイン」という言葉も「モデル」という言葉も要求分析の文脈の言葉であるし、どんな分析手法を取るにせよドメインエキスパートと会話しながら分析を行わなければドメインモデルを明らかにすることはできない。 無論、数百ページに及ぶ要件定義書を書けという話ではない。スクラムで言えばスプリントバックログに入れる前にフィーチャーのモデリングは終わらせておけというだけの話である。ス
DDDとロラン・バルト
昨年（2021年）12/16に増田亨さん主催のイベント「エヴァンス本のススメ」に参加した際、エヴァンス本の読み方と絡めてロラン・バルトの「エクリチュール」概念を紹介したのですが、あまりに唐突でちょっと喋っただけでは伝わらなかったろうなと思うので改めて記事にまとめたいと思います。 ここではタイトルに「DDDと…」としていますが、本質的にはエヴァンス本や他の技術書籍に限らず、より広くプログラミングやソフトウェアの書き方とロラン・バルトの『零度のエクリチュール』についての話です。 TL;DR 技術書やプログラミングを、言語、プログラミングスタイル、そして指導的設計思想（＝エクリチュール）の3つのレイヤーに意識しながら読んでみましょう。 エヴァンス本のDDDでは、Smalltalk的なメッセージパッシングによるオブジェクト指向が指導的設計思想として背景にあります。 是非はともかく、そうした設計思想
トランザクションスクリプトとDDD
エヴァンスが2003年に書籍 Domain-Driven Design で紹介してから早17年。 やっと時代が追いつき、近年ではこれまでにないほど DDD が注目を集めている。 注目が高まるとともに、DDD を取り扱う良質な書籍も増え、 私自身も複数の DDD の実践を経て、以前よりも理解は進んできたように思う。 そこで、私の現時点での DDD に対する解釈を、一度ここに書き起こし、残してみようと思う。 (これはあくまで現時点での解釈であり、解釈のアップデートがあれば書き換えるかもしれない。) なお本稿では、ドメインエキスパートや、ユビキタス言語といった、 DDD のプロジェクトへの適用側面には触れず、あくまでプログラミングする際に どのように理解、適用していけばよいかを中心に見ていく。 2011年9月、Spring Framework 3.0.6がリリースされて間もない頃、Spring
達人プログラマー(第2版): 熟達に向けたあなたの旅 作者:Andrew Hunt,David Thomas発売日: 2020/11/21メディア: 単行本 先日紹介した「UNIXという考え方」以外にも、定期的に読み返す価値の有る技術書がたくさん有る。まだまだ読んでいない本も無限に有るので、Twitterで募集したところ、川島さんに3冊教えていただいた。 ・The Pragmatic Programmer ・Release It! ・PofEAA どうしてもベタになりますね…— :craftsman/kawasima (@kawasima) 2020年11月14日 その中でもちょうど「The Pragmatic Programmer(邦題：達人プログラマー)」が20周年記念の第2版翻訳が出たばかり(2020年11月20日発売)だったので、早速注文してみた。 「達人プログラマー」は、Davi
【感想】『良いコード／悪いコードで学ぶ設計入門』：コードの悪魔討伐の旅へ！ 【前編】 - Rのつく財団入り口
“良いコ／悪いコ”で悪魔討伐！ (お排泄物)コード撲滅！ 前々から本で出ることは聞いていたのですが、爆殺シリーズやク〇コード動画でおなじみのミノ駆動さんのコード設計を扱った本がついに2022/4に商業本で登場。東京ですと書泉ブックタワーでのコンピュータ書籍ベスト1を4週連続達成など、かなり売れています。 エンジニア界隈では早速GW中などに読んだ方も多いようでネットでも反響が大きく、感想記事もよく見かけます。Twitterでもハッシュタグ #ミノ駆動本 で毎日のように反響を見ることができます。 僕もGW明けから拝読しました。とても学びの多い本でしたので以下、章ごとに感想を。 “良いコ／悪いコ”で悪魔討伐！ (お排泄物)コード撲滅！ 1 悪しき構造の弊害を知覚する 2 設計の初歩 3 クラス設計 ―すべてにつながる設計の基盤― 4 不変の活用 ―安定動作を構築する― 5 低凝集 ―バラバラにな
週刊Railsウォッチ: Railsコアチームとコミッターに新メンバー、ruby-buildでのRust YJITサポートほか（20220524後編）｜TechRacho by BPS株式会社
こんにちは、hachi8833です。Railsコアチームに3名、Railsコミッターに2名の新メンバーが加わりました。おめでとうございます！🎉 Please welcome @kamipo, @_byroot, @jhawthorn to Rails Core and @yahonda, Jonathan Hefner to Rails Committers! 🎉 https://t.co/0DS6Z8aMKt — Ruby on Rails (@rails) May 23, 2022 週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションを
RailsにおけるServiceクラスに関する設計的な話は、プロジェクトの性質や開発チームの状況によって色々な意見があり、これといった解りやすい結論が出ていない状況だと思っています。 この状況において、ある程度の規模のOSSのServiceクラスの活用事例を取り上げて、考察することは意義がありそうだと思いました。 また、ServiceクラスのアイデアはRailsやWeb開発に関わらず、幅広い分野のソフトウェア開発で適用できるものなので、そういった意味でも価値がありそうだと思い、記事にしてみました。 対象とするOSSプロジェクトは、爆速技術記事サービスで有名な dev.to です。 まず、dev.toにおけるServiceクラスの活用方法を見た後で、ソフトウェア設計に関する名著である、Patterns of Enterprise Application Architecture と Doma
はじめに 普段、Ruby on Railsで開発しています。サービスクラスは元々Railsにないクラスですが、ファットコントローラやファットモデルを解消したりするために導入することがあると思います。 上手く使えばファットなコードをスリムにしてくれる便利なサービスクラスですが、一方でこんなサービスクラスはイヤだなと思うこともあります。 どんなサービスクラスがイヤだと思うのか、どうしてそうなるのか、どうすれば防ぐことができるのか、といったことをポエムとしてお伝えしたいと思います。 サービスクラスとは？ chatGPTによると 「ビジネスロジックやデータ処理、外部APIなどの機能を提供するクラスのことです。サービスクラスは、コントローラーから呼び出されることが多く、ビジネスロジックを分離することで、アプリケーションのメンテナンスや拡張性を高めることができます。」 Railsの標準にはないので、a
天下一バリューオブジェクト牛丼談義｜Ryo Aita
今も熱い牛丼談義が続いている。僕も自転車置場で牛丼はつゆだくがうまいとか、卵は半熟か生かどうかとか話すのは大好きだ。僕は最近、大盛りを食べるのはちょっときつくなってきた。それはともかく、せっかくだから僕もバリューオブジェクトの天下一牛丼談義に参戦しよう。 天下一牛丼談義への参戦のきっかけは、かとじゅんさんがバリューオブジェクトはドメイン固有型の一種であるという解釈を記事で紹介していて、それは違うんじゃないかと思ってtweetをしたことだ。これにはかとじゅんさんから回答をもらうことができた。しかし、まだいくつかの疑問が残っているので、ドメイン固有型とドメインオブジェクトとはなにかという議論を通じて、バリューオブジェクトと不変条件、そしてバリューオブジェクトとは結局は何であるのかというのを、ここで整理していきたい。 バリューオブジェクトはドメイン固有の型なのか？ドメイン固有型(値オブジェクト含
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsを主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ
Smart UI パターンが再評価される世界 - id:onk のはてなブログ
DDD本を読むためには前提知識が非常に多いよ - Qiita
レイヤードアーキテクチャ - kawasima
ドメイン固有型(値オブジェクト含む)を再考する - かとじゅんの技術日誌
DDDの正体は実装パターンとモデリングの組み合わせ - パンダのプログラミングブログ
ドメイン駆動設計の源流のPofEAAを読んでみる | フューチャー技術ブログ
メモ:値オブジェクトの定義と差異について - かとじゅんの技術日誌
値オブジェクトへの誤解が生まれる一つのストーリー - 文脈と定義を大事にする
Clean ArchitectureとEffで変更に強いAPIを設計する
変化に適応するソフトウェアアーキテクチャと組織構造への道程 - クラウドワークス エンジニアブログ
翔泳社セール対象商品(PDF)のうち定番ぽいタイトル11冊 - 日記移転予定地
ドメイン駆動設計を成功させるためのICONIXプロセスを考える
RE:メモ:値オブジェクトの定義と差異について｜Ryo Aita
より良いトランザクションスクリプトを目指す - enrike3のブログ
YAPC::Kyoto 2023 に参加した - はこべにっき ♨
技術的負債を草の根活動で改善していった話｜グロービス・デジタル・プラットフォーム
「達人プログラマー第2版」を読んだ、そしてまた読もう、何度も読もうと思った - Magnolia Tech
dev.toのServiceクラスについてDDDとPofEAAを読んで考察してみた
Railsでサービスクラスを書く時に知っておきたいこと - Qiita