AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く
![CQRS+ES(再)入門](https://cdn-ak-scissors.b.st-hatena.com/image/square/0f62219e5cd98ecabfb0ab3590d47996811ce008/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Feb30d2c6a17648bb82103d8ea4cc93a5%2Fslide_0.jpg%3F12434540)
「クリーンアーキテクチャ」とは、DDDの文脈における「ドメインモデル」をシステムの中心にすえ、「入力」「永続」「出力」などの多方面で抽象化を行うことで、高度に変化への強さを獲得できるアーキテクチャです。昨今の変化の早さに対応するべく「アジャイル開発」や「マイクロサービス」が叫ばれているように、「クリーンアーキテクチャ」もまた日増しにその注目度は上がっているように感じます。 しかし、やや取っつきにくいアーキテクチャであることからか、現状参考になる資料が無数に転がっているというわけでもありません。そこで、エキテンで現在Laravelベースで開発中の新しい予約システムを題材に、実際にアーキテクチャを形作っているコンポーネントの紹介や、開発する上で行ってみたちょっとした工夫、開発フェーズにおける現場の生の声などをお話しようと思います。
はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は
The Qiita Advent Calendar 2019 is supported by the following companies, organizations, and services.
この記事は宮崎IT関連勉強会 Advent Calendar 2019の16日目の記事です。 ドメイン駆動設計も随分と浸透してきたなぁと思うこのごろ。 でも、未だに動的型付き言語で頑張っている(弊社含め)現場も多く、今回は静的型付き言語について語ろうかと。 そもそもWebアプリの業界では単純にPHPやRuby、Pythonなど動的片付け言語で頑張る現場が圧倒的に多いかと思います。 しかし、ドメイン駆動設計を実践していくと、ある事実が襲ってきます。それはドメイン駆動設計は「型」の世界で成り立っているということ。 実践するにあたって、まず最初に乗り越える壁がレイヤアーキテクチャだったりするので、なかなか難しいと思いますが、本質的な部分は当然モデル。EntityであったりValueObjectであるわけです。 もちろん、動的型付きの言語でもモデルは書けます。弊社でもPython3の型ヒントを駆使
はじめに 私自身は今年の 7 月にドメイン駆動設計(DDD)を実践する企業に転職したばかりで DDD 実践歴は浅いのだが、最近は開発業務の他にも中途採用者の DDD 教育や 現場で DDD!2nd のドライバー役をする機会を頂くなど、DDD の布教活動にも少し関わっている。 その中で「DDD ムズイ」という言葉をよく聞いたので、DDD の実践に悩んでいる人向けにサンプル問題の解説を通して、実は DDD 自体は難しくないんだよってことを教える目的で本記事を書いた。 TL;DR(最初に結論) DDD 自体はドメインを中心にモデリングと実装をイテレーティブに繰り返す設計プロセスであり、モデリングと OOP の理解があれば誰でもできる。 難しいのは DDD 自体ではなくて、モデリングまたは OOP である。特に「良いモデル」を得ることは非常に難しい。 なので「DDD ムズイ」と感じる人はモデリング
昨今のシステムは社内外のシステムと連携していて境界定義が難しいといわれます。マイクロサービスの文脈でもどのようにシステムを分割するかの議論があります。実はこれは50年来続く「部品の分割=モジュール化」の歴史といえます。最近ではこの部品の分割単位としてドメイン駆動設計の「ドメイン」がよく話題になります。「モジュール」と「ドメイン」にどんな関係があるのでしょうか。Chatwork社でのマイクロサービス化の事例も踏まえながらマイクロサービス設計を「モジュール」と「ドメイン」の軸で語りたいと思います。
オブジェクト指向のハードコアは2019年5月25日にゼロベースサロンで行われたイベントです。「オブジェクト指向」というキーワードについて、プログラミング、デザイン、哲学などの分野を横断しつつ知的な議論ができました。記録映像は必見。 企画意図/招待状 この研究会の企画意図については、私が送った招待状を見ていただくのが早いでしょう: いくつか異なる分野で「オブジェクト指向」がキーワードとして注目されています。昨年からGUIデザインの分野では「オブジェクト指向ユーザーインターフェイス」(OOUI)の議論がホットです。ソフトウェア開発の分野では、数年前からオブジェクト指向の見直しとしての「ドメイン駆動設計」(DDD)が広まっています(※原著である英語版から日本語への翻訳は数年遅れています)。さらには「オブジェクト指向存在論」(OOO)も思想業界でブームになっています。 これはもうオブジェクト指向の
@kawanamiyuu です。この記事は「ドメイン駆動設計#1 Advent Calendar 2019」の 6 日目の記事です。 1. はじめに 2. ドメインの依存関係に対するアーキテクチャテスト 2.1. 人事労務管理システムのドメイン 2.2. ドメインの依存関係 2.3. ドメインの依存関係に対するアーキテクチャテスト 3. レイヤーの依存関係に対するアーキテクチャテスト 3.1. シンプルなレイヤーアーキテクチャ 3.2. 依存関係を逆転したレイヤーアーキテクチャ 4. さいごに 1. はじめに 最近、技術イベントやまた社内でも「ドメイン駆動設計」や「クリーンアーキテクチャ」についての話題をこれまでにも増してよく耳にするようになりました。 私も楽楽労務という実際のプロダクト開発で 1 年以上、ドメイン駆動設計に取り組んできました。ドメイン駆動設計 チョットデキル ような気が
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
Use Design-Level Event Storming to identify Aggregates, UX mockups, and other design elements. Just follow this agenda through your first facilitation! So, here you are! You have identified a business-critical bounded context. (Remember, bounded contexts are just functional areas) It is the perfect occasion to use Design Level Event Storming! Let’s see how to get started! Big Picture is about expl
業務で扱う(最小)単位でデータとロジックをひとまとめにして整理する技法 ドメインモデルが実現する世界 どこに何のロジックが書いてあるか、(ソースを見るだけで)わかる 改修しやすいプログラム ドメインモデルで解決したい問題 どこに何のロジックが書いてあるかわからない問題 - わからないから適当に書く→適当に書くからわからない → わからないから・・・ - ある修正をしようと思っても、どこまでが影響範囲かわからない - 使用している箇所全grepして調査 - 同じような処理、分岐が重複してしまう これを解決したい。これだけを考える。 なぜ(今までのシステムは)改修は難しいのか 機能クラスと、データクラスをわけてしまうから そのデータクラスを呼べる箇所 = 業務ロジックがかけてしまう どこになにが書いてあるかわからなくなる 共通クラス、Utilクラスを作ってしまうから 誰でも呼べる = そのクラ
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をそのまま「商品クラス」と設計してしまうこと。 単純な商品クラスは、往々にして出品、予約、注文、発送など、様々なユースケースのクラスと結合してしまいがちです。 商品クラス自体も、結合したクラスに関連する知識(ロジック)を持ち始め、どんどん巨大化複雑化していきます。
DDDを冠するイベントや勉強会が、異様といっていいほどの盛況である。なぜそんなに人気があるのか。DDDが「オブジェクト指向プログラミングをもっとうまくやると同時に、開発者のドメイン知識の不足を補ってくれる方法」と思われているからではないだろうか。 そこには基本的なレベルの勘違いがあるような気がする。DDD本の中でも語られているように、開発者は個別案件が対象にしている特定ドメインに肉薄しなければいけない。そのためには、近傍のドメイン知識を事前に身につけておく必要がある。当然ながらそれは、DDDの実践だけでは身につかない(身につくとしてもひどく効率が悪い)。 「必要な知識はドメイン・エキスパートが補完してくれるから大丈夫。それがDDD」などと甘えてはいけない。ドメイン・エキスパートのカジュアルな語りからシステムのあり方を洞察するには、広範囲のドメイン知識や多能工的スキルに裏打ちされた総合力が要
Spring Bootで始めるDDD 1. Spring Bootで始めるDDD ドメイン駆動設計導入 第一章 2. 今日話すこと ● DDDを実際の開発に導入するためにやったこと ● Spring BootでDDDを実現するために行なったこと ● 既存システムをDDDで置き換えるためにやっていく予定のこと 3. DDD導入の背景 4. サービスの成長と複雑度の増加 ● サービスの拡大 ● 開発メンバーの増加 ● アプリケーション知識の複雑化 ● 開発・テスト工数の増大 5. トランザクションスクリプト public void updateXxx(Long value) { Xxx xxx = dto.selectXxx(value); if (xxx.xxx = "xxx") { xxx.setFoo("XXX"); dto.updateXxx(xxx); dto.updateXxx(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く