#forkwell_library #100 での発表資料。 (このイベントのアーカイブ動画 https://jobs.forkwell.com/events/s4rpcjtbs?argument=249xHStF&dmai=a6847939e883d8) ① AI技術とソフトウェア設計 ② …

DDDは今も“武器”になるのか? ここ1年でプロダクト開発の環境は大きく変わりました。 AIエージェントが開発現場で“当たり前”のように使われる時代になりつつあります。 そんな中で、「DDD(ドメイン駆動設計)って今の時代にも必要なの?AI時代になったらもう使わなくなるのでは?」と疑問に思う方もいるかもしれません。 私はこう思います。 DDDは、AI時代にこそレバレッジを効かせることができる、価値を届けるための“武器”になる。 (少なくとも、あと数年はね。) DDDの目的は「機能性」と「保守性」を両立させること DDDは単なる設計理論ではなく、プロダクトを継続的に改善・成長させていくための戦略です。 その本質は、以下の2点に集約されます。 ① 機能性を高めるためのモデリング ユーザーや業務の課題を理解し、抽象的な図を使ってFBサイクルを小さく・速く回すことにより、役に立つものを作れる可能性
こんにちは、プロダクト開発部の中田です。 最近、AIエージェント界隈は非常に盛り上がっていますね。 今回は、Clineを使ってみた感想や、自分が現在どのように使っているかをご紹介します。 はじめに Clineを使いはじめたわけ Clineを使いはじめて悩んだこと AIを使用するうえでの保守性の高いコードベースの重要性 コンテキストの局所化 自然言語としての可読性 実際のタスク分担の例 バックエンド開発タスク UseCaseのユニットテスト実装 Controller実装 Repository実装 フロントエンド開発タスク コンポーネントライブラリの実装 個別コンポーネントの実装 やってみて効果を実感したTIPS 参考にしたい既存コードをVSCodeで開いておく Planですり合わせしてからActする .clinerulesファイルを活用する Clineとのやりとりを記録・共有する Cline
DDDは理論を知った時には完璧に思えるもので、「これが正しく実践できれば素晴らしいコードが書ける!」と感じたものです。 一方でいざ実装に入ると「え、これってどう書くの・・・?」という場面に何度も遭遇し、理想と現実の乖離に何度も悩まされることとなりました。 今回はその迷いの要因となるDDDのトリレンマから考察を深めていきます。 DDDのトリレンマ DDDのトリレンマの初出はおそらく『Domain model purity vs. domain model completeness (DDD Trilemma)』で、日本では2023年1月ごろから話題になり始めました。 記事の例をもとに解説すると、たとえば以下のようなUserモデルがあったとします。 type User struct { company Company email string } func (u *User) ChangeEm
AI に自分のスタイルでコードを書かせたい。 自分のコーディングスタイルを端的にまとめると、たぶんこう。 TDD でミニマルにはじめるのが好き でも DDD で段階的にドメインモデリングもしたい 実装は関数型ドメインモデリングに寄せる これをAIに叩き込みたい。資料を読ませてプロンプトを作って、それにそって実装させる。 エヴァンスのDDDと軽量DDDの2つでやらせてみる。 コードはここ 自分のコーディングスタイルに合わせたプロンプトを作成する MCPエージェントで検索とURL展開を使える状態で次のように指示をした。(自作ディープサーチみたいなもの) インターネットでDDDについて調べさせる インターネットで関数型ドメインモデリングについて調べさせる インターネットでTDDについて調べさせる プロンプトとして使えるように要点を圧縮しろ 端的に圧縮しろ もっと圧縮しろ で、でてきたのがこれ。こ
はじめに ドメイン駆動設計(DDD)は、ビジネスドメインをソフトウェアに正確に反映させるための強力なアプローチです。その中でも、状態遷移の設計は、ドメインの振る舞いを表現するための核となる部分です。ドメインモデルで「状態」をどのように扱うかは、システム全体の品質に大きな影響を与えます。 例えば、注文管理システムでは、注文が「未処理(注文時)」→「処理中」→「配送中」→「配送完了」と遷移する過程を管理する必要があります。この状態遷移を正しく設計しないと、システムが次第に複雑化し、コードの可読性や保守性が低下します。最悪の場合、ビジネスロジックの不整合やバグが発生しやすくなるため、注意が必要です。 状態遷移設計の課題 ナイーブな状態遷移の実装における典型的な課題には、以下のようなものがあります。 本質的ではない条件分岐 ドメインロジックの本質ではない条件分岐をドメイン層に書かなければいけません
DDD以外の設計手法についてご教示いただきたく、DDDの主張をある程度正確に理解した上でDDDをこき下ろしているイメージの強いくまぎさんに質問させていただきました。 最近はソフトウェアの設計について調べると、DDDについての記事ばかりで辟易する一方、私がエンジニアになった頃にDDDに勢いがあった影響もあって私自身DDD以外の良い設計とされているものを知らず、DDDに胡散臭さを感じつつもDDDの考え方にとらわれている、毒親の影響を受けた子供のような状態から抜け出せずにいます。 その最たる例がリポジトリパターンです。 よく依存性の逆転・DIと一緒に語られますが、くまぎさんがおっしゃる通り余計にインターフェースを切るのはイケてないと感じます。また、DI抜きにしても、リポトリパターン由来の様々な問題(N+1やバルクアップデート、管理画面用のメソッド生やしたくなる問題など)に対する解決策として提示さ
こんにちは、リファクタリング大好きなミノ駆動です。 2024/07/20に発売された『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』を、訳者の増田亨氏よりご恵贈賜りました。 この記事は、この書籍の感想です。 著者の許可を得た上でのだいたんな意訳総評等の前にいの一番で伝えたいポイントです。 エリック・エヴァンス氏の『ドメイン駆動設計』は大変価値の高い知見が網羅されている一方、「ユビキタス言語」や「境界づけられたコンテキスト」といった独特の用語が登場したり、難しい言い回しをしていたり、読解がかなり難しい書籍です。 独自用語が登場するたびに「ユビキタス言語?なんだこれ?」とつまづきを覚え、内容理解に集中できず、読む手が止まってしまったことがある人も少なくないのではないでしょうか。 本書『ドメイン駆動設計をはじめよう』は『Learning Domain-Driv
ドメインイベントを扱う実装は様々な流派があり、本記事ではなるべく一般的なものを取り上げたいと思っていますが、あくまで一例です。 実装例は Kotlin を使っていますが、他の言語でも同様の実装が可能です。 ドメインイベントとは イベントとは「過去に発生した出来事」であり、ドメインイベントは「ビジネスドメイン上で発生した重要な出来事を表すメッセージ」です。 (例: チケットが割り当てられた、注文がキャンセルされた) ドメインイベントはシステム内の状態の変化(=集約の状態の変化)を表現するものであり、通常は集約がドメインイベントの発生源となります。 用途 ドメインイベントは主に次のような目的で使用されます。 1. イベントの発生を起点に、別の処理をトリガーする ドメインイベントは、システムの異なる部分間を連携させるために使用されます。 ドメイン上の要件として「...したら...する」のようなフ
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ?って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB(RDBMS)を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
TypeScriptとドメイン駆動設計(DDD)を組み合わせ、APIを構築するハンズオンガイドです。この本では、DDDとは何かという基礎的なところからソフトウェア開発における戦略的設計、戦術的設計まで、包括的な知識を提供します。 戦略的設計では、ビジネスの要求に合わせたドメインモデルの設計をイベントストーミングを用いて行います。その後、戦術的設計では、具体的なコードの実装に関連するDDDの原則と実践を学びます。 TypeScriptを使ってコードを書きながら、DDDの概念を実際のプロジェクトに適用するヒントを紹介します。
最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います! 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ
自分の開発に対する姿勢を根本的に変えたドメイン駆動設計(DDD)。ぜひみんなにもその面白さを知ってもらいたい!と思い社内向け資料を作成、さらにSpeakerDeckにて公開としました。 たのしんでご覧ください! 関連note記事はこちら:https://note.com/jgc_parallel…
概要 こんにちは。サーバーサイドエンジニアの窪田です。 これまでの戦術的DDDについて以下のような記事で紹介してきました。 戦術的DDDをGoで実現する【entity編】 - Yappli Tech Blog 戦術的DDDをGoで実現する【Value Object編】 - Yappli Tech Blog Deep Moduleという観点から戦術的DDDのRepositoryの設計を考えてみた - Yappli Tech Blog 今回は戦術的DDDにおけるトランザクションの扱いについて注目します。 トランザクションは一見インフラ層の関心ごとなのでインフラ層で完結するように思えますが、DDDの本にある例では、ユースケース層で張っているソースコードの例が紹介されています。 なぜ、そのような設計になるのかを考えていきます。 DDDとトランザクションの関係 DDDとトランザクションは実は深い関係
またクラスを利用していないため、オブジェクト指向の特性「継承」「カプセル化」「ポリモーフィズム」は利用していません。この部分が厳密なドメイン駆動設計(DDD)のニュアンスと異なるので「風味」という言葉を使っています。 全体概要と用語の整理 まず初めにドメイン駆動設計の全体の概要と出てくる用語について紹介します。 自分は言葉を理解しないとコードの理解に落とし込めなかったので詳しく解説をしていきます。 各用語の具体的な実装は後の章で紹介します。 すべての用語において理解しやすいように「ユーザー管理システムを実装する」例を用いて解説を入れています。(解説の都合で書籍とは異なる例を採用しています) ドメイン駆動設計とは ドメイン駆動設計はその名の通り、「ドメインの知識」に焦点をあてた設計方法 「ドメイン」とは、ソフトウェア開発におけるプログラムを適応する対象となる領域 ドメインについて ドメイン駆
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く