サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
speakerdeck.com/j5ik2o
AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く
ドメインイベントは過去に起きたドメイン上の出来事を意味します。「過去に起きた」なので後から変更できません。つまり不変(イミュータブル)なモデルです。 昨今、このドメインイベントはCQRS/Event Sourcingやマイクロサービスなどの書籍で取り上げられ、実際に実装上でドメインイベントが利用される事例も増えています。このように有益性は認識されつつありますが「うちはEvent Sourcingじゃないのでイベントは関係ありません」と視野が狭くなっている方もいます。 たとえ実装で使えなくても、ドメイン分析に基盤的な視点を与えてくれるのがドメインイベントです。 ともあれ、この資料は「そもそもドメインイベントはソフトウェア設計にどのような影響を与えるのか」を解説します。
クラウドを採用しても、スケーラビリティやレジリエンス(回復力)は自動的に得られるものではありません。スケーラビリティやレジリエンスはサービスの応答性の問題であり顧客の関心事です。あらゆるシステムでこれらの非機能要件は必ずしも高レベルではありません。しかしシステムから応答性が失われた際は、ユーザから見限られる可能性が高くなります。最悪は代替サービスに乗り換えられてしまいます。そのような事態を招かないために私たちエンジニアにできることはないかアーキテクチャの側面から考えます。
世の中にはクラウドを採用していても、スケーラビリティのないサービスを開発・運用しているエンジニアは少なくないと思います。過去の私もその一人でした。CQRS/Event Sourcingはその解の一つです。私自身も2016年にCQRS/ESに出会って以来、AWS上でその根本的な課題に取り組んで来ました。その経験を生かしてAWSでの実現方法について解説します。
ChatworkではリアクティブシステムとCQRS/ESを反映した次期アーキテクチャを構想しています。まだ構想段階ではありますが、なぜそれらを採用するのかメリット・デメリットも含めてご説明します。
昨今のシステムは社内外のシステムと連携していて境界定義が難しいといわれます。マイクロサービスの文脈でもどのようにシステムを分割するかの議論があります。実はこれは50年来続く「部品の分割=モジュール化」の歴史といえます。最近ではこの部品の分割単位としてドメイン駆動設計の「ドメイン」がよく話題になります。「モジュール」と「ドメイン」にどんな関係があるのでしょうか。Chatwork社でのマイクロサービス化の事例も踏まえながらマイクロサービス設計を「モジュール」と「ドメイン」の軸で語りたいと思います。
RDRA1.0とDDDを組み合わせた経験から以下の観点 について解説 1) いきなりドメインモデルを考えられるか 2) ドメインモデルの周辺環境を探索する
過去に僕が失敗した代表例から今ならどう設計するか、という観点でお話します。中心になるトピックは以下です - 軽量DDDの功罪 - ドメインモデル貧血症対策 - 集約の境界定義の善し悪し
There is a movement to configure Akka-Cluster on Kubernetes and build a system that is resilient and scalable. Because Akka is a toolkit for developing distributed applications across nodes, it requires orchestration capabilities such as deployment scaling at the container level. In that sense, Kubernetes is now a viable option. EKS has just arrived in the Tokyo region, so I think this kind of int
DDDコミュニティでは、なぜドメイン駆動設計をやるのかという必要性の議論ではなく、何をどのように実践するのかという議題に変わっています。Scalaコミュニティにおいても、DDDの実践方法に強い関心があることはいうまでもありません。 長大な設計哲学を説くDDDは、読み難く理解し難い、実践までの道のりが遠いという定評があることは事実です。今回は、そういった悩みを持つ方向けに、Scalaコードを交えながら、ミクロで実践的な観点でドメインモデリングの手法を解説します。
実装コードを中心に、ドメインモデルの設計に対する考え方や改善方法についてまとめた資料です。
ドメイン駆動設計の考え方は書籍を読むとわかりますが、いざモデリングを実践しようとすると、どこから手を付けていいかわからない、ドメインモデリングの始め方がよくわからないという意見を聞きます。 このスライド資料では、そんな悩みを持つ皆さんに向けて「ドメインモデルを見つけ出し・実装に落とし・改善していく」方法を、できるだけわかりやすく解説します。
社内勉強会の資料。
AWS Summit 2017 Tokyo, Dev Dayで登壇した際の資料です。
DDDを具体的なプロセスに落とし込むにはどういう観点が必要だろうか。 - 境界づけられたコンテキストがどこまでの範囲かよくわからない - ユビキタス言語やドメインモデルをどのように発見すればいいかわからない。どこから着手すればいいのか? - ドメインモデルがただのデータの入れ物になってしまう(貧血症) という問いに答えるには、RDRA, ICONIXを検討するとよいというテーマの資料です。
ChatWork社内勉強会で発表した際の資料
Actorの設計プラクティスに関して簡単にまとめた資料です
ChatWorkのScala採用プロダクト "Falcon" リリースまでの失敗と成功の歴史
システムの非機能要件は以前より高い要求を求められる傾向にあります。 たとえば、 – より多くのコアを使うには? – より短い応答時間にするには? – 限りなく0時間に近いダウンタイムにするには? – ペタ規模のデータを扱うには? などと考える機会が増えたと思います。 このような背景で登場したコンセプトが、”レスポンスが速い・障害に強い・負荷に応じてスケールする” 特徴を持つリアクティブシステム(リアクティブプログラミングのことではありません)です。最近注目されているので、言葉だけは耳にしたことがあるのではないでしょうか。クラウドやビッグデータ基盤の進化に合わせてアプリケーション設計の考え方も転換する時期だから注目されているのかもしれません。しかしながら、リアクティブシステムは登場してまだ間もないので、今後に備えてその鼓動を感じてもらえるセッションにしたいと思います。 そして、このリアクティ
次のページ
このページを最初にブックマークしてみませんか?
『speakerdeck.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く