ChatworkではリアクティブシステムとCQRS/ESを反映した次期アーキテクチャを構想しています。まだ構想段階ではありますが、なぜそれらを採用するのかメリット・デメリットも含めてご説明します。
リアクティブシステムとCQRS/ESで実現する Chatwork新アーキテクチャについて
ChatworkではリアクティブシステムとCQRS/ESを反映した次期アーキテクチャを構想しています。まだ構想段階ではありますが、なぜそれらを採用するのかメリット・デメリットも含めてご説明します。
ドメイン駆動設計に関する何か - 日々常々
2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ
ドメイン駆動設計を理解する３つのキーワード - ソフトウェア設計を考える
ドメイン駆動設計との出会い １０年前に、エヴァンスのドメイン駆動設計を初めて読んだ時は、書いてある内容がほとんど理解できなかった。 あまり、面白いとも思わなかった。 当時は、現場でバグだらけのコードと格闘していた。障害が報告されるたびに、リファクタリング本を参考に、該当個所の長いメソッドや大きなクラスを片端からリファクタリング。その結果、コードがわかりやすくなり、やっかいなバグが単純な修正で解消できてしまうことの効果に驚き、設計の重要性を再認識していた。 それ以前は、UNIXとC言語、OracleとPL/SQLという、オブジェクト指向ではない世界で技術を身に着けてきた。 どちらかというとオブジェクト指向には、ネガティブな印象を持っていた。現場では役に立たんだろうと。 バグとの格闘の中で、リファクタリング（設計改善）の威力を肌で感じ、その考え方とやり方がオブジェクト指向に由来するということを
ドメイン駆動設計とOOUXで迎える2019年 - Qiita
概要 DDDが、デザイン界隈で注目されだした「OOUX」という設計手法を吸収合併すると皆んながハッピーになるはず、という主にはUI設計のお話です。 OOUXとは Object-Oriented User eXperience の略で、端的に言うと、UIを設計する際「（ユーザのアクションでなく）オブジェクト視点で設計するとより直観的なUIが作れるよ」という手法 1です。考え方自体はOOPが提唱された時代から（OOUIという呼び名で）あったようなのですが 2、UX界隈では2016年頃から話題にのぼるようになりました。 このアドベントを見ている方はほぼエンジニアだと思うので、UI設計者の進化についての、個人的な解釈・経験に基づく乱暴な説明（下記1〜３）から始め、それをDDDでさらに進化できる！という私の思いの丈（4）を語り、この場を借りてDDUXという言葉を提唱したいと思います 3。 UX以前の
「実践ドメイン駆動設計」を読んだので、実際にDDDで設計して作ってみた！ - Qiita
こんにちは、クラウドワークスの新規事業のエンジニアとして仕事をしている高梨です！ 最近、「実践ドメイン駆動設計」という本を読みました！ 500ページ近くもある技術書で、なかなか量は多かったのですが、DDDがどんなものなのか一通り大枠を掴めた気がします。 ただ読み終わった後にこんな疑念や不安をいだきました。 「たしかにかなり面白そうだけど、実際にやるとどれだけ工数かかるんだろう...？」 「設計の話は全然出てこなかったけど、DDDで作るとなるといったい何から始めればいいんだ？」 「戦術についての知識はついたけど、実際に書こうとしたらできなそうだな...」 そこで、そういった疑念や不安を解決するために、実際にDDDでサンプルプロダクトを作ってみようと思ったわけです。 実際に作ってみるのが、結局一番理解が進みますしね。 今回は、そのプロダクトがリリースされるまでの過程や感想を、作成した設計書やソ
非エンジニアの方に「DDDって何なの？」と聞かれたときの説明[ドメイン駆動設計] - little hands' lab
この記事はドメイン駆動設計 #2 Advent Calendar 2018の16日目の記事です。 DDD(ドメイン駆動設計)とは何なのか そもそもDDDってなんなの？ということをちょくちょく聞かれます。 一言で言うと、「開発手法の一種です」ですが、それだと「ふ〜ん」で終わってしまうので、もう少し興味を持ってもらえる回答を考えます。 まず、開発してて何に困るのかがわからないと思うので、そこから説明をします。 非エンジニア向けの説明 開発手法にも色々あり、行き当たりばったりに作ると以下のような問題に突き当たる、ということがよくあります。 実際の業務をきちんと理解しないで作ったら、 リリースしてもあんまり使われなかったり不評なものができる きちんと整理されてないプログラムを書いたら、 あとから修正するのがどんどん大変になる DDDは、このの2個とも解決しよう、ということで生まれた設計・開発手法な
![非エンジニアの方に「DDDって何なの？」と聞かれたときの説明[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/e3e4fa7f31b58bd9de8ce7f63d37588d4385b09e/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20181217%2F20181217062304.png)
ドメイン駆動設計の道標 - sandbox
この記事は 2016年 第2のドワンゴアドベントカレンダー、20日目の記事です。 qiita.com ドメイン駆動設計に関して悩める若者に送るポエムを書いていたら長くなりました。 20日目なはずなのに今日は 12/25 ですが、お察しください。 TL;DR ドメイン駆動設計には3つの顏がある それは「哲学」「戦略」「戦術」である 「戦術」にスポットがあたりがちだが、まず「哲学」とコアの「戦略」から理解する プロダクトにおけるドメインモデルの全体像を描いてから「戦術」を検討しよう ドメイン駆動設計をどの程度取り入れるかの 「ドメイン駆動設計の適用レベル」について はじめに ドメイン駆動設計(DDD)、以前と比較して認知が上がってきたのか、よく「DDD やってるんですか?」 「DDD ってどうはじめればいいんですか?」と聞かれることがあります。そしてこの時にまず話に上がるのが、エンティティ、集
ドメインモデルをコードへ落とす 〜あなたのクラスは、どこから？〜 - Qiita
annotation: 現在コメントいただいている通り、一部誤りを含んでいる様です。 追って確認・修正いたしますが、現行ではコメントも合わせてお読み頂ければと思います。 こんにちは、風邪はだいたい喉から来るぷーたんです。 「DDDの構成要素はこれだー」というのはたくさんあったのですが、 「このドメインオブジェクトはどの要素だー」と逆引きするものがなかったので調べてフローチャートにしてみました。 例えばドメインモデル図とコードがうまく合致しない時の見直しなどに使えるのではと考えています。 ではご覧ください♪ 検討フローチャート 図1.フローチャート 1) 複数のドメインオブジェクトを扱い、整合性を担保するか まず複数のドメインオブジェクトを扱うかを考えます。 ドメインモデル図では集約線が引かれていたり、複数の関係線が引かれていたりします。 図2.ドメインモデル図の例 上記のような場合であれば
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
makopi23のブログ 「ユースケース駆動開発実践ガイド」で扱っている題材「インターネット書店」の環境構築
ICONIXプロセスという手法を扱っており、DDD本の次に読む本としてもオススメだと思います。 ただ日本語版の初版が2007年発行（原著はもっと前！）なので、この書籍で扱っているプログラム題材「インターネット書店」を動作させるための環境構築にチョト苦労した・・・ 10年以上前と今では、Spring FrameworkやTomcat、その他諸々のOSSのバージョンの差異がかなりデカいのよね。 せっかくなので、環境構築の手順について纏めておくことにする。Javaを普段使ってない読者向け。 ちなみに、ここで紹介する方法が正解というわけではないので注意！ とりあえず動作させるためにやってみた一例です。 makopi23のPC環境は以下の通り。IDEはEclipseとTomcatが両方入ってる「Pleiades All in One」を使っている。 Windows 7 (64ビット)Eclipse
ドメイン駆動設計について DroidKaigi 2017 で登壇しました。
長らく Y.A.Mの雑記帳というブログでAndroidの技術情報を発信しています。最近はなかなか投稿できなくなってしまいましたが、それも仕事としてAndroidに関われているためです。Androidを触り始めたころはまだ学生だったので時間があったんでしょうね。 はじめて Android に関するエントリを投稿したのは 2009 年 5 月 24 日です。当時はJavaFXを触っていたので、NetbeansでAndroidをやろうとしていたようです。 当時のAndroidのバージョンは1.5、Fragment もなく、Support Library もなく、マルチタッチすらなく、ストアは Google Play ではなく Android Market という名前でした。 ここから2、3年くらいは、仕事でAndroid アプリを開発している人はもっぱらメーカーのプリインアプリを作っている方たち
#yapc8oji 得票数4位トーク「あの日見たM V WhateverのModelを僕たちはまだ知らない」実況中継 - Re.Ra.Ku tech blog
丸山です。ヤパチー、最高に楽しかったですね。スライドの公開はしたのですが、正直重要なことは全部口頭で説明していて、スライドには情報が少ない。しかし、動画を見るのは正直だるい。40分もPCの前で集中して映像を観れないですよね。知ってる。というわけで、受験参考書の「実況中継」シリーズ（知ってます？）方式で、プレゼンをブログで再現します。長いぞ。でも多分動画見るよりははやく読み終われる。ぜひ読んでいってください。 アバンパート 今日はこういうトークをします。 簡単に自己紹介すると、こういうものです。 息子紹介です。かわいいですね。 WEB+DB Press 91号では特集を、92号ではPerlHackersHubに記事を書かせてもらいました。もう原稿料いただいてるので、もうこれ買ってもらってもわたしには一銭も入らないんですけど、いい雑誌なので買ってないひとはぜひ買って読んでください。 まずMVW
Domain Driven Design in Go – Citerus – Utvecklar människor och mjukvara
In 2008, Citerus developed a Java sample application in close collaboration with Eric Evans, based on the examples in his book. The purpose was to showcase the concepts from DDD in a real-world application. Since then, the application has been ported to other languages such as C# and Ruby. Of course, as a DDD practitioner and a Go developer I thought it might be a fun exercise to try porting it to
makopi23のブログ 「DDD Alliance! ドメインオブジェクトの見つけ方・作り方・育て方」に参加しました
2016/5/25(水) 「DDD Alliance! ドメインオブジェクトの見つけ方・作り方・育て方」に参加してきました。 connpass http://ddd-alliance.connpass.com/event/31834/ 場所は銀座の株式会社ドワンゴさんです。 参加者は１００人くらいでしょうか。毎度の満席です。 これまでDDDAllianceの講演は、（無料のは）ほとんど皆勤で参加してます。 いつも学びが多く、今回も楽しみでした。 以下、スライドに無い口頭説明部分を中心に、メモ。 講演 最初に 今日は、自分たちがどうやってDDDをやってきたか、をできるだけ生でお伝えできればなぁ。 ドメインオブジェクトの設計の話は 「オブジェクト指向エクササイズ ９つのルール」とか 「リファクタリング」とか バートランド・メイヤーのモジュール性の話とか これらを私自身、勉強してきたし、現場でこ
CQRSの小さな演習(1) 現実の問題 - 考える場所
2016 - 02 - 20 CQRSの小さな演習(1) 現実の問題 作ったもの 考えたこと システム開発とエンジニアリング ドメイン駆動設計 CQRSの小さな演習 仕事で業務向けのWebアプリケーション開発をしています。その中でもいろいろな問題がやはりあるのですが、特に大きな問題だなと思えることがあります。エンハンスや保守改修が続くと、もうなにがなんだったか分からなくなってしまうことです。私はもう20代でもなくて、記憶力が衰えてきているということもあるのですが、問題はそこではないでしょう。むしろ、個人の記憶力が頼りになってしまうというのはおかしいことです。しかし、それが現実だということです。 仕事ではどうしてもこの現実から脱却できないということがあります。正直なところ、モダンな開発スタイルを取り入れている現場の雰囲気は分かりません。私が長いこと携わっている現場がそうではないからです。優先
DDD Alliance! ドメイン駆動設計のためのオブジェクト指向入門に参加してきた - はむはむエンジニアぶろぐ
2016年1月21日に開催されたドメイン駆動設計のためのオブジェクト指向入門に参加してきました。 その時のスライドがこちら ドメイン駆動設計のためのオブジェクト指向入門 from 増田 亨 www.slideshare.net 発表内容のメモを残しておく 私のDDDに対する解釈が、混じったメモになります。 DDDは、インクリメンタルな設計である。 ドメインに対する理解(ベース)をもとに、オブジェクト指向で表現する。 ドメインモデルとは、ドメインの知識を鋭く解説する。 ドキュメントで、長ったらしく解説するより語彙が大事。 モデルと実装は結びつけろ。 開発の生産性 変更容易性 が、もたらされる。 日常で使われる言葉をコードで体現する。 ドメインを分析する人と実装する人が別れてはいけない。 ドメインを分析する人がコードを書き、コードを書く人が、ドメインを分析する。 クラスを作るためには、分析が必
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計 ～ユーザー、モデル、エンジニアの新たな関係～
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計 本格入門
ドメイン駆動設計のガイドライン: Capture - Embed - Protect
