Domain Event
目次 概要 この記事の内容 対象読者 注意事項 前提知識 定義 用途 モデリング 不変性 独立性 汎用情報 個別の情報 Versioning 実装 前提 フレームワーク Domain Eventの処理 型定義 interface DomainEventEnvelope Enum Domain Eventの内部通知 staticなEvent Publisherを用意してAggregateがPublisherを呼び出す 実装例 AggregateのCommandの返り値としてDomain Eventを返す 実装例 Aggregateで保持してGetterで取り出す 実装例 永続化と外部通知 要件 永続化 外部通知 まとめ 参考文献 概要 この記事の内容 Domain Eventは非常にシンプルな概念かつ強力なモデリングパターンです。 モデリングにおいては直感的に扱うことが可能ですが、実装をする
はじめに 本記事は、今年発売された書籍『データモデリングでドメインを駆動する――分散／疎結合な基幹系システムに向けて』を読んだ感想と、QAエンジニアである私*1が日々の業務で役立ちそう（既に役立った）部分を紹介します。今のところ、本書籍は2024年のベストバイな気がします。 gihyo.jp 本記事で一番伝えたいこと データモデリングについての考えが深まるぞ 開発者が読むともっと役立てることができると思うぞ QAエンジニアである私が読んでも役立つぞ 読み始めてすぐに「良い買い物だった」と思って思わずポストしている様子 目次 はじめに 本記事で一番伝えたいこと 目次 本書籍で良かったこと：データモデリングをするにあたっての整理と用語の提案がすごい SoAとSoMという整理 「残」という概念 データベース設計とは違う「データモデリング」という考え方 QAエンジニアとして、業務に役立てそうなこと
はじめに こんにちは、バックエンドエンジニアの@zawaです。 私は入社以来、1年ほどショップオリジナルの「メンバーシップ」（会員制度）を開設できる「メンバーシップApp」の開発に携わってきました。 少し前になりますが、2024年2月末にメンバーシップAppの特典交換機能をリリースしました。 リリース内容の詳細はぜひこちらをご覧ください！ baseu.jp メンバーシップAppは、モジュラーモノリスのアーキテクチャ上に構築しており、モジュール内部ではドメイン駆動設計（以下、DDD）を採用しています。 先日公開された動画の中でも紹介していますので、ご興味がある方は是非ご覧ください。 【前編】クリーンアーキテクチャの柔軟性を生かしたメンバーシップAppの開発の道筋 - YouTube 【後編】クリーンアーキテクチャの柔軟性を生かしたメンバーシップAppの開発の道筋 - YouTube 本記事で
DDDでレガシーコードに立ち向かうリアル / Reality of confronting legacy code with DDD
DDDでレガシーコードに立ち向かうリアル / Reality of confronting legacy code with DDD
ログラスにおけるコード品質でビジネスに貢献する仕組み・カルチャー / A system and culture that contributes to business through code quality in Loglass
mtx2sさん・ログラス飯田さんと考える！コード品質が及ぼすビジネスへの影響 #コード品質_findy https://findy.connpass.com/event/313471/ 参考リンク アジリティを支える品質特性 https://speakerdeck.com/twada/agility-and-quality-characteristics-developers-summit-2021-summer 強くてニューゲームなプロダクト開発 https://speakerdeck.com/yoshikiiida/product-development-in-new-game-plus ログラスQAのミッション・ビジョン・バリューを策定しました（品質富士山について） https://note.com/k_kotatsu1992/n/nd639aa4b5692 ログラスを支える設計標準
RustとDDDでAPIサーバーを構築する
はじめに Rust と フレームワーク axum を使って、API サーバーを実装してみました。 対象読者 Rust で API サーバーを実装したい人 Rust で DDD を実装したい人 説明しないこと Rust の基本的な文法 DDD の基本的な考え方 使用クレートの使い方 依存の方向 今回の作成する、アーキテクチャの依存関係は、上記のようになります。 上記の依存関係を頭の片隅に置いて、記事を読み進めていただけると、理解が深まると思います。 インフラストラクチャレイヤーは、アプリケーションレイヤーと依存しないことが重要です。 いざ、実装 仕様を決める 今回は、大学が、サークルを管理するシステムを作ることにしました。 メンバーを追加できる 4 年生は、追加できない メンバーを削除できる オーナーは削除できない 4 年生は、卒業する サークルは最低 3 人以上でないと、活動できない サー
イベントストーミングによるオブジェクトモデリング・オブジェクト指向プログラミングの適用・開発プロセスの変遷・アーキテクチャの変革 / Object modeling with Event Storming.
Object Oriented Conference 2024 にてお話ししました 【アブストラクト】 本トークでは、イベントストーミングを活用したオブジェクトモデリングの実践が開発プロセスとアーキテクチャにどのような変革をもたらしたかについて詳しくお話しします。 「どのようなオブジェクトを実装するのか」 この単純な問いに私たち開発者は多くの悩みを抱えています。 イベントストーミングの結果として得られるモデルはこの問いに対する解答の示唆に富んでいます。 その有用性を認め、私たちは過去２年間、組織的にイベントストーミングに取り組んでまいりました。 もちろん、ただイベントストーミングを採用すれば、それですべて片付くといったものではありませんでした。 イベントストーミングの採用は開発プロセスを一変させました。 アーキテクチャの選定基準を変えました。 組織的に取り組むには多大な努力と適応が求められ
2024年3月24日に開催されたObject-Oriented Conference 2024の登壇資料です https://fortee.jp/oocon-2024/proposal/7c795ce1-68cf-48eb-bb24-e0321fc0f8c4
"Object-Oriented Conference 2024" の登壇資料です。 https://ooc.connpass.com/event/305241/
Object Oriented Conference 2024 登壇の機会をいただいたので、ここ数年、設計について考えていることを、言語化してみました。 はじめに 設計と開発プロセスの関係性 ソフトウェア設計の知識と技能 ① ソフトウェア設計の基礎知識 a. 基本課題 b. 解決のアプローチ c. モジュール化：基本となる４つの技法 ② モジュール化 a. モジュールの分類 b. オブジェクト指向プログラミングのモジュール化 c. ドメイン駆動設計のモジュール化 ③アプリケーションのモジュール構成（参照モデル） コア（中心） ポート（境界） アダプタ（周辺） ④モデル駆動設計 全体 事業活動、要件、アーキテクチャ コア（中央） 業務ロジック、ドメインモデル 業務機能、アプリケーションサービス アダプター（周辺） 記録モデル、データベーススキーマ 連係モデル、プロトコル設計 対話モデル、イン
ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP
Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に代数的データ型などの関数型のパラダイムを加えたよりタイプセーフな関数型DDDを紹介します。 本セッションではドメインモデリングによって発見したモデルやビジネスロジックをソフトウェアに反映する際により型を重視した設計を加えます。 型で表現する範囲が広がることでビジネスロジックをより明確にコードで表現できるようになります。 さらには型で表現されているためコンパイルフェーズで気付けるミスが増え、ソフトウェアの品質向上にもつながります。 関数型の考えをいれるといってもただ単にHaskellなどに代表される関
会計システムのアーキテクチャとモデリング ~会計というドメインを Rust で表現している話~ - CADDi Tech Blog
はじめに こんにちは。 バックエンドエンジニアの松本です。今回は、会計システムの開発を通じて、 CADDi におけるプロダクト開発の様子を紹介します。 2024年3月現在、CADDiでは2つのサービスを提供しています。1つは図面データ活用クラウド「CADDi Drawer」で、もう1つは加工品製造サービス「CADDi Manufacturing」です。 今回、後者の加工品製造サービス「CADDi Manufacturing」向けに、 会計システムを構築しました。これは、生産管理システムや拠点管理システムから取得した各種情報を基にして、会計仕訳データを生成し、経理部門に公開する役割を持ちます。 はじめに 会計システムのアーキテクチャとその狙い 計算処理を少しずつ進める 会計数値の妥当性をダッシュボードに表示する 会計システムのモデリングと最初の開発 仕訳の流れを整理して、ドメインモデル、デー
DDD入門：コーディング編
はじめに こんにちは、クラウドエース Backend Division 所属の秋庭です。 この記事はDDD入門：用語解説・モデリング編に続くコーディング部分の記事となっています。 対象 想定読者 DDD におけるコーディング部分についてこれから学ぼうと考えている方。 用語解説・モデリング編を既に読んでいただいた方。 記事内容 「用語解説・モデリング編」を踏まえ、ここからはコーディングを行って実装に落とし込んでいきます。 前提としているドメインモデル図や用語の情報は前記事をご覧ください。 コーディング 作成したドメインモデル図を元に、コーディングを行っていきます。 作成したドメインモデルをただコーディングするだけではなく、前記事のモデリングとコーディングの関係に記述したように「ソフトウェアに反映させやすい」ドメインモデルであるかなど、ドメインモデルをブラッシュアップさせる事も意識しながらコー
DDD入門：用語解説・モデリング編
はじめに こんにちは、クラウドエース Backend Division 所属の秋庭です。 私は今年新卒で入社したのですが、入った案件では DDD (ドメイン駆動設計)を元に設計・実装が行われていたため DDD について学ぶ必要がありました。 この記事は、私が何も知らない状態から DDD について学び始めた一歩目のアウトプットであり、同様にこれから一歩を踏み出す方の手助けになるものとなったら嬉しいです。 この DDD 入門記事は大きく「用語解説・モデリング編」と「コーディング編」に分かれており、用語の紹介と実際の作業を通して DDD の概観を紹介できればと思います。 この記事は「用語解説・モデリング編」となります。この記事の続きとなる「コーディング編」もぜひご覧ください！ 対象 想定読者 DDD の用語や概念、モデリングについてこれから学ぼうと考えている方。 記事内容 この記事では主に DD
前書き 業後に以下のDDDイベントに参加してきた。 その議事録とアウトプットとしてここに残す。 画像の上２つが自分が書いたものである。 ドメイン駆動設計概要とユビキタス言語 コンテキストマップとコアドメイン 全体像を俯瞰したコンテキストマップ→その上でのどこにモデリングコストかけるか策定。コアドメインの時間経過に伴う変化(動き)、境界の位置含めて。詳細での検証の上で演繹的に前提となるマクロな境界の位置を修正。 それに対して参加者の方から、 ①コンテキストマップからのコアドメインの定義という順番(トップダウン寄り) ②コアドメイン先に定義してからのコンテキストマップ作成という順番(ボトムアップ寄り) どちらなのか？ という良い質問があった。 どっちかというとコアドメインを最初に特定して、それを支える業務サービスとして他のドメインがあるため、わりとボトムアップ式にコンテキストマップ作成という話
はじめに ドメイン駆動設計（Domain-Driven Design、DDD）という単語はエンジニアをやっていれば1度は聞いたことがあると思います。1 しかし特徴的な名前が多く、ちょっととっつきにくい印象がありますよね。 私も正直、何度か本を読んでは挫折し、を繰り返しています。 今回、Software Design 2024年3月号の特集記事であった「ドメイン駆動設計[実践]ガイド」の第2章「ユビキタス言語 定義と効果を理解しチームで実践してみよう」が大変わかりやすく、「たしかに『ユビキタス言語』、大事！」と感じました。 自社プロダクトの開発をしていると、たとえ「ユビキタス言語」という単語を認識していなくても、開発者は「ユビキタス言語」を定義することの重要性をわかっていて、なんとかそれを捉えようともがいています。 ただ、もがく過程で特集記事にあったポイントや定義の流れを念頭に置くと、スムー
どうも、ばやしです。 2/27に行われたJoe Yoder : Domain modeling techniques for designing microservicesに参加してきたので、参加レポです。 なお私はDDDに詳しいわけでもなく、英語もおぼつかないので誤っている部分があるかもしれませんが、ご了承いただければと思います。 www.eventbrite.com どんな研修だったの？ ドメインモデリングを中心にドメイン駆動設計(以下DDD)の概念を学びつつ、それがどうマイクロサービスに役立つのかを学ぶ研修でした。 具体的にピザ屋のシステムや、交通違反システムを例に挙げてDDDの概念を理解しつつ、ワークショップではクレジットカードシステムを題材にイベントストーミングやマイクロサービスアーキテクチャ設計などを行いました。 全編英語だったのですが 英語で講義 日本人同士で日本語でワークシ
https://increments.connpass.com/event/310090/ 2024/03/01「Wantedly x Qiita Meetup #2 Rubyを用いたプロダクト開発」の資料です。 本発表では、モデリングという役割を持つバックエンドエンジニアこそ、 開発段階からユビキタス言語作りを主導すべきという話をします。
このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
課題意識 特定の商品を数量を指定して購入できるECサービスのドメインモデルを表現とします。TypeScriptで構築する際に、「数量」を単にnumber型で扱うことは可能ですが、よりロバストな設計を目指す上で以下の2つの方法論があります。 Refinements(値の制約を表す): 「数量」は一般的に自然数です。1度の注文で指定できる上限を設けるビジネスルールがあると仮定します。この場合、number型に「自然数」「上限付き」の制約を加えた値として表現します。 Branded Types: (同じ構造の型を区別する): 「価格」などの他のnumber型と混同されないように、これらの数値を型レベルで区別したいです。JavaやC#に見られる公称型の概念をTypeScriptで模倣するBranded Typesのテクニックを用いることで、これらの誤った利用を型システムで防ぐことができます。 Br
Functional Domain Modelling - Marco Emrich and Ferdinand Ade - DDD Europe 2023
Domain-Driven Design Europe 2023 https://dddeurope.com - https://twitter.com/ddd_eu - https://newsletter.dddeurope.com/ https://linkedin.com/company/domain-driven-design-europe Organised by Aardling (https://aardling.eu/) Modern collaborative methods such as EventStorming help to bring together subject matter experts and developers. Domain Modelling goes one step further and enables joint work d
フロントエンドの複雑さに立ち向かう 〜DDDとClean Architectureを携えて〜 | さくらのナレッジ
自己紹介 さくらインターネットではシニアフロントエンドエンジニアをやっています。代表作は「NES.css」というファミコン風CSSフレームワークで、エイプリルフールには「さくらのINFRA WARS」というゲームの企画開発をしていました。 話さないこと 本記事ではソフトウェア設計ということで、以下の設計・アーキテクチャに関しては話す予定はありません。コンポーネント設計や CSS 設計に関しては過去に記事やスライドを公開していますので、気になる方はそちらを参考にしていただければと思います。 コンポーネント設計 加速するコンポーネント設計入門 / Component Design as an Accelerator コンポーネント指向時代のmargin戦略 / Rethinking the relationship between Components and Margins CSS設計 OO
「全ては会社の競争力を生み出すために」アーキテクチャを刷新し、ドメインモデリングも組織再編もエンジニア教育も一つ一つ丁寧に積み上げてモダナイズを進めた話｜CTOロングインタビュー - MonotaRO Tech Blog
独自のビジネスモデルを持ち、競争優位を獲得しているモノタロウ。事業拡大に合わせて、モノタロウの成長をテクノロジーで支えるTech組織も進化してきました。現在Tech組織は、より高度なビジネス価値を生み出せるようにするため、サプライチェーンの高度化、パーソナライゼーションでの商品検索に着目し、アーキテクチャの再構築とシステムのモダナイズに取り組んでいます。また、そこに向けて組織体制のアップデートやカルチャーの醸成にも力を入れています。 今回は、MonotaRO CTO 普川泰如氏のインタビューから、その実態に迫っていきます。まず第1章ではモノタロウが会社として掲げるビジョンとビジネスの特徴について説明します。それを踏まえて第2章では、そのビジョンやビジネスを実現するためのシステムとその課題、モダナイゼーションについて、第3章ではその技術的な取り組みを実行するためのTech組織の体制について紹
ドメイン駆動設計を実践して自分の LINE 環境をリファクタリングしてみた（実装編２） | DevelopersIO
間が空いてしまいましたが、Lambda リファクタリングの最終回です。空いてしまったのはこのあともこの環境を使おうかと GitHub の環境構築に手間取ってしまったためでして。 こんにちは、高崎＠アノテーションです。 はじめに 設計：ドメイン駆動設計を実践して自分の LINE 環境をリファクタリングしてみた 実装：ドメイン駆動設計を実践して自分の LINE 環境をリファクタリングしてみた（実装編） の続きになります。 残りのソースをそれぞれ書いて説明していこうかと思いましたが、記事が長々となってしまったため GitHub に置きました。 1 今回の記事では clone 後の利用方法と、各機能についてを実装したことを記載しますが記事内では抜粋して記載しますので詳細は GitHub のソースをご参照ください。 なお、今回もお約束として正確性としては程遠い可能性もあり、エラーチェックも甘い実装例
はじめに 実行環境 ディレクトリ構造 app migrations/model pyproject.toml ソースコードと簡単な解説 app/core app/core/abstract app/core/decorator app/core/exception app/core/interface app/core/middleware app/core/mixin app/ddd app/ddd/application app/ddd/application/schema app/ddd/application/schema/studnet app/ddd/application/usecase app/ddd/application/usecase/student app/ddd/domain app/ddd/domain/student app/ddd/infra app/ddd
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
仕様の複雑化、過渡期特有の難解なコード、技術スタックの老朽化… システムの健全な成長を妨げる要因に対する基本戦略 アーキテクチャ刷新の現場：未知の技術を採用するために #1/2 アーキテクチャ刷新の現場における取り組みと成果を発表 成瀬允宣氏：みなさん、こんにちは。GMOインターネットグループでデベロッパーエキスパートとして活動しています、成瀬允宣と申します。本日はよろしくお願いします。 私、所属はGMOインターネットグループ株式会社で、システム統括本部に所属している一般のプログラマーではありますが、私からお送りするお話は、「アーキテクチャ刷新の現場」で、ここ数年……2年ほどですかね、アーキテクチャを刷新する現場で一番前を走っていたので、その現場のお話をしようかなと思っています。 非常に苦労して、やっと花開いてきたところなので、今日は、何を予測して、何を準備して、そして何を失敗したのか。そ
2024/01/17 Product Engineer Night #2 〜DomainへのDeep Dive！〜 に登壇した際の資料です。 https://product-engineer.connpass.com/event/305777/ X: https://twitter.com/moeka__c
実録レガシーコード改善 / Working with Legacy Code: the True Record
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエピソードとコードをプロダクトオーナー（引き継ぎ前のコードを書いた本人）の許可を得て使用しています。登場するコードは全て本物、登場するデータは講演用の架空のものです。
ミノ駆動さんに「なぜ負債解消にDDD？」と聞いたら、ソフトウェア開発の本質に気づかされた 2024年1月15日 株式会社スタメン ミノ駆動（仙塲大也） 電子機器メーカーや大手精密機器メーカー、クラウドワークスを経て、2021年4月にREADYFORに入社。アーキテクチャの変更容易性や機能性を促進する設計構造を目指し、リファクタリングやドメインモデリングを主軸としたシステム設計に従事する。現在は、組織改善のためのエンゲージメントプラットフォーム「TUNAG」を擁するスタメンに在籍。ITエンジニア本大賞2023技術書部門大賞を受賞した『良いコード/悪いコードで学ぶ設計入門』著者としても知られる。 X（@MinoDriven） note Qiita 株式会社スタメン・テックブログでの執筆記事 ドメイン駆動設計（以下、DDD）に注目が集まりだしてしばらく経ちますが、いまだに捉えづらさを感じている人
ドメイン駆動設計に触れてから2年たったので、開発者の取り組み方について振り返ってみる - commmune Engineer Blog
はじめに こんにちは、コミューンの中でSuccessHubというプロダクトの開発者をしている中野です。 SuccessHubは正式にローンチされてから1年半弱経過しており、開発初期からドメイン駆動設計を基に開発を進めています。この経験を通じて、コードベースのアプローチ以外の部分でも、開発者としての取り組みに関する課題や成功体験が浮かび上がってきました。今回はその一部を振り返りつつお話しできればと思います。（少し抽象的な話になります） はじめに モデル同士の関係性がうまく表現できない モデルが変化している 共通言語が貧しくなってきた 開発者としての姿勢 コミュニケーション 技術だけで解決しようとしない ドキュメントに起こして満足しない まとめ 最後に モデル同士の関係性がうまく表現できない SuccessHubローンチ直後、新規プロダクト開発記 〜どうしたら業務知識をコードに落とし込めるのか
TypeScriptとドメイン駆動設計（DDD）を組み合わせ、APIを構築するハンズオンガイドです。この本では、DDDとは何かという基礎的なところからソフトウェア開発における戦略的設計、戦術的設計まで、包括的な知識を提供します。 戦略的設計では、ビジネスの要求に合わせたドメインモデルの設計をイベントストーミングを用いて行います。その後、戦術的設計では、具体的なコードの実装に関連するDDDの原則と実践を学びます。 TypeScriptを使ってコードを書きながら、DDDの概念を実際のプロジェクトに適用するヒントを紹介します。
0063 号 巻頭言
DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
The Go gopher was designed by Renée French. Illustrations by tottie. はじめに この記事は、ドメイン駆動設計（DDD）の中核概念である「リポジトリ」についての理解を深めることを目的としています。リポジトリの基本的な役割と重要性を確認し、Go言語での実装の例を紹介します。 前提 リレーショナルデータベースからデータを取得（更新）するアプリケーションを想定しています サンプルコードは Go 言語で書かれています リポジトリとは まずは、リポジトリの定義を確認してみましょう。 リポジトリパターンとは: リポジトリは、データベースから取得したデータを構造体にマッピングし、ドメインオブジェクトにアクセスするためのインターフェースを提供します。 これは、一般的なリポジトリの理解と相違ないですね。次に DDDの文脈で、より詳しい定義をみ
手元にある LINE ボット環境のソースファイルが 1 ファイルにも関わらず 350 行超えたので、最近勉強したドメイン駆動設計を実践も兼ねてリファクタリングしてみました。 こんにちは、高崎＠アノテーションです。 はじめに 過去の拙記事にも何度か登場している自身の LINE ボットの環境ですが、cdk のスタック定義が約 100 行、Lambda のソースが約 370 行と注ぎ足し注ぎ足しでだんだんと大きくなってきました。 一方、業務で使用している環境はドメイン駆動モデルを元に設計・構築を行っているものが多いため、これらの環境やドメイン駆動設計を学んだことを実践すべく、この LINE ボット環境をリファクタリングしてみました。 この記事の対象 筆者と同じく「ドメイン駆動設計を始めたばかりの方」向けと考えております。 今回の内容は筆者個人が参考文献を元に記載した記事で、ドメイン駆動設計の正確
アーキテクチャの進化はドメインイベントが起点になる - KAKEHASHI Tech Blog
こちらの記事はカケハシ Advent Calendar 2023 Part2の24日目の記事になります。 adventar.org はじめに 反復的な開発は、変更容易性の高いソフトウェアが不可欠です。ソフトウェア開発の経験がある方なら、デリバリ後の洞察や市場環境の変化から、新しい機能の追加やアーキテクチャの進化の必要性に直面したことが一度はあるでしょう。 私自身、要求分析手法やSOLID原則等の技法を取り入れ、変更容易性に対応する多くのプロジェクトに参加しました。しかし、どれだけ優れた手法や技法を持っていても、変更が難しい要求が出てくることは避けられません。その際、「過去の出来事」を正確に記録していれば、後から見返して問題解決が容易だったと感じることがよくあります。 ドメイン駆動設計（DDD）では、「過去に起こった出来事」を表現するドメインモデルを「ドメインイベント」と呼びます。変更容易性
こんにちは、近藤です。 commmune Advent Calendar 2023 18日目の記事は『TypeScriptにおけるDDDのドメインオブジェクトの課題と対策』です はじめに ドメイン駆動設計（DDD）は、複雑なビジネスロジックを扱うアプリケーション開発において、重要かつ効果的なアプローチとして広く認識されています。 コミューンでは、現場で役立つシステム設計の原則の著者、増田さんのご協力を得て、プロダクト開発を進めています。 幸運なことに私は増田さんとの密なコミュニケーションを取らせて頂いており、DDDの理論と実践方法に関する貴重な知見を深めその有用性を感じております。 しかし、TypeScriptのような構造的型付けを採用する言語でDDDを適用する際には、特有の課題が生じることがあります。本記事では、TypeScriptでの構造的型付けに伴う課題、そしてそれらを克服する方法に
フロントエンドの複雑さに立ち向かう / Tackling Complexity of Front-end Software with DDD and Clean Architecture
フロントエンドの複雑さに立ち向かう 〜 DDD と Clean Architecture を携えて 〜 さくらのテックランチvol.6 〜ローストチキンのフロントエンドパスタとクリスマスFigmaケーキ〜 https://sakura-tokyo.connpass.com/event/303232/ YouTube配信アーカイブ https://www.youtube.com/watch?v=usmLmI1bj74&t=472s ドメイン駆動設計（Domain-Driven Design）や Clean Architecture をヨイショもディスもせずフラットな立場で評価し、現実解を探りながらフロントエンドの複雑さに立ち向かった半年間の軌跡
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 の17日目の記事です https://qiita.com/advent-calendar/2023/loglassこんにちは。ログラスでエンジニアをしております、南部です。 ログラスでは、当アドベントカレンダーの5日目の記事で紹介されていますように、「DDDもスクラムも当たり前」な開発組織が形成されています。 私は、今年の9月からログラスに入社していますので、上記の記事で紹介されているログラスのDNAを受け継ぐ側に当たるかと思います。 そしてちょうど直近で、DDDの文脈においてこのDNAの価値を感じる機会がありました。 実は、前職でもDDDっぽいコードを取り入れたりはしていたのですが、それによって特にメリットは得られておらず悩んでいました。 結論、原因は私の不勉強でDDDの価値を出せる条件となって
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
QAエンジニアから見た『データモデリングでドメインを駆動する』書評 - ブロッコリーのブログ
メンバーシップAppの開発とDDDの実践から得た学び - BASEプロダクトチームブログ
戦略的DDDを実践するための跳躍力 / OOC 2024
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
設計の知識と技能で駆動するソフトウェア開発
Software Designドメイン駆動設計に参加 - Qiita
「ユビキタス言語」とは？ - ドメイン駆動設計の用語の理解を試みる - Qiita
ドメインモデリングとマイクロサービスの研修に参加してきたよ - ばやしのブログ
ユビキタス言語はバックエンドエンジニアから始めよう
どのレイヤー（層）でトランザクションを実装すべきか
ZodでAlways-Valid Domain Modelを実現する
PythonでDDDやってみた💪 - techtekt
DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
仕様の複雑化、過渡期特有の難解なコード、技術スタックの老朽化… システムの健全な成長を妨げる要因に対する基本戦略
エンジニアはどのようにドメインにダイブできるか
ミノ駆動さんに「なぜ負債解消にDDD？」と聞いたら、ソフトウェア開発の本質に気づかされた
はじめに｜【DDD入門】TypeScript × ドメイン駆動設計ハンズオン
【DDD入門】TypeScript × ドメイン駆動設計ハンズオン
DDDを実践するためのリポジトリ層の設計（Go言語による例）
ドメイン駆動設計を実践して自分の LINE 環境をリファクタリングしてみた | DevelopersIO
TypeScriptにおけるDDDのドメインオブジェクトの課題と対策
「DDDもスクラムも当たり前」な開発者組織に入って気付かされたDDDの価値を出すための条件｜南部豪