Object-Oriented Conference 2020で登壇させていただきました。 その際の発表資料です。 発表資料 DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか from Koichiro Matsuoka www.slideshare.net 本章の内容は技術書典8(2020/3/1)で頒布予定の「ドメイン駆動設計 モデリング/実装ガイド」の1,2章の内容になります。 全部で11章仕立てです、興味お持ちいただけたらお買い求めください。 受け取りは技術書典以降になりますが、それでもよろしければboothで予約可能です。 little-hands.booth.pm また、実践にあたって頻出の疑問に対してトピックごとに詳しく解説した書籍もあります。 重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具

CQRS（Command Query Responsibility Segregation、コマンド・クエリー責任分離）は、現代のアプリケーション設計において重要な役割を果たしているが、今回はよく議論になる一貫性・可用性・スケーラビリティについて書いてみよう。文章のみの説明なので、非常にイメージしづらいかもしれないけど。 一貫性と可用性の評価軸CQRSが一貫性と可用性を重要な評価軸として採用する理由は、CAP定理に基づいている。分散システムでは、ネットワークの分断や障害が発生した場合、一貫性と可用性の間でトレードオフが生じることが避けられない。CQRSはこのトレードオフを巧みに活用し、書き込みモデルで一貫性を、読み込みモデルで可用性を重視することで、最適なバランスを見つけることを目指している。 一貫性への影響イベントソーシングを伴わないシンプルなCQRSでは、非CQRSベースのシステムと同

どんな強力なツールでもそうであるように、CQRS（Command Query Responsibility Segregation）は無料で使えるわけではない。CQRSにはコスト（手間という意味）が伴うが、その利点も多い。 従来のアーキテクチャより複雑だと批判されることもあるCQRS/ES（Event Sourcing）だが、実際にはシンプルに実装できる部分もある。 CQRSにおけるモデルの分割CQRSではシステムを分割し、書き込みモデルと読み込みモデルを独立させる。例えば、ホテルの部屋を予約するシステムを考えると、部屋を予約する・宿泊人数を変更する・予約をキャンセルするなどの行為は書き込みモデル（集約ルート）に該当し、顧客別予約・ホテル別予約などの情報は読み込みモデルになる。この分割により、各オブジェクトはより単純化されるが、システム全体としての複雑さは増す。これは、CQRSにおける重要

背景 開発チームが抱えるよくある課題として システムが変化する一方でドキュメントは更新されず腐る メンバーの流入出によって口伝でかろうじて継承された知見も失われる 検索性が良くないと過去のドキュメントが気づかれず、同じような内容のドキュメントが新規量産される 後から参加したメンバーはどちらが正のドキュメントか分からず混乱する といったことが良くあります。 解決方法としては以下のように、GitHub＆ルールベースで管理するといった例があります。 future-architect.github.io また組織・システムが大きくなってくると認知負荷を低減するためにドメインで区切るような形でチームの分割が始まりますが、 異なるチームによってシステムが管理され、システムの依存関係を全て知っている人がいなくなる CxOレイヤが大規模イベント前に現状を把握したいときに都度時間がかかってしまう チームごと

ソフトウェアと経営マガジン第75回です。組織改革に取り組むにはまず正しい現状認識から、ということで今回と次回は課題のヒアリングと整理についての考え方を書いていこうと思います。前編では、まずヒアリングを重ねようということで、どのようにして課題をかき集めるか、それによって生み出すべきアウトプットとはなにか書いていこうと思います。 記事に対する疑問や感想、意見などXでのポストや記事へのコメントをいただければ、今後のコンテンツの改善に役立てさせていただきます、よろしくおねがいします。 前回の記事はこちら。 課題ヒアリングと分析改革の第一歩は自分自身の組織を正しく知ることだ。自身の組織を知る上では①課題②KPI構造③人を私は重視している。その上でまず知るべきは自身の組織の課題構造である。課題は点ではなく線、構造的なものであるという前提に立って、まずはこれらを収集・整理してみよう。 課題ヒアリングで求

私は今までのキャリアの中で、CTOのいない会社に3回入社してきました。うち2社はEMとして入社してVPoEになりました。そこでの反省はもちろんありますが、成果を出すことができました。そして1社は、なんと3週間で退職しました…。 OPENLOGI Advent Calendar 2023で今年は何を書くか考える中で、私のようにCTOがいない会社に何度も入社した経験があるEMはそうそういないのではないかと思いました。将来CTOのいない会社に入社するCTO・VPoE・EMといったマネジメント層の方に、私の経験から学んだことを参考にしていただければと思います。 ※OPENLOGIには現在CTOは在籍しております。 CTOのいない会社とは CTOのいない会社とは、エンジニア組織のトップであるCTO・VPoE・開発部長といった立場の人がいない、もしくは、トップはいるけれど何らかの理由（トップがエンジニ

この記事は 食べログアドベントカレンダー2023 の23日目の記事です🎅🎄 こんにちは。食べログシステム本部 技術部 仕入チームの@shohei-yです。 今回は、新規事業の「食べログ仕入」プロダクト開発において所謂「設計書」を書かない設計に挑戦して開発効率を向上させた話を書きます。 （結局「書くの？書かないの？どっちなんだい！」と感じた人は、ぜひ読み進めてください。） 所属している仕入チームについてはこちらの記事をご覧ください。 目次 なぜ設計書を書かない設計に挑戦したのか 設計書を書かないチーム 設計書を書かないことによる問題 1. チーム協力の課題 2. ソースコードの複雑化 3. チーム変動に関わる問題 設計工程導入のきっかけ 設計書を書かない挑戦の背景 設計書を書かない設計 フロントエンド・バックエンドのインターフェースの明確化 ソースコードのスリム化対策 設計のレビュー方法