【DDD入門】TypeScript × ドメイン駆動設計ハンズオン
TypeScriptとドメイン駆動設計（DDD）を組み合わせ、APIを構築するハンズオンガイドです。この本では、DDDとは何かという基礎的なところからソフトウェア開発における戦略的設計、戦術的設計まで、包括的な知識を提供します。 戦略的設計では、ビジネスの要求に合わせたドメインモデルの設計をイベントストーミングを用いて行います。その後、戦術的設計では、具体的なコードの実装に関連するDDDの原則と実践を学びます。 TypeScriptを使ってコードを書きながら、DDDの概念を実際のプロジェクトに適用するヒントを紹介します。
フロントエンドの複雑さに立ち向かう / 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 をヨイショもディスもせずフラットな立場で評価し、現実解を探りながらフロントエンドの複雑さに立ち向かった半年間の軌跡
認可のベストプラクティスとDDDでの実装パターン
最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います！ 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ
事業組織全体で取り組むドメインモデリングのすすめ
sumirenです。 経営管理（事業計画作成、財務Modeling）SaaS「Zaimo.ai」を開発するZaimo株式会社で、技術顧問としてドメインモデリングや組織設計のアドバイザリを行っています。 Zaimo.aiでは、スケール後もドメインモデリングを事業全体で活用できるよう、創業間もないフェーズからドメインモデリングを組織的に活用するカルチャーづくりに励んでいます。 ドメインモデリングというと、DDDのような重厚なプロセスを想像される方が多いかと思います。同時に、技術が目的と化している熱狂的DDDファンも少なくないことから、ドメインモデルというワード自体に拒否反応を覚える方もいると思います。 しかし、ドメインモデリングはもっと手軽に使えるものであり、エンジニアリングのみならず、事業全体にインパクトをもたらしうるものと筆者は考えています。この記事では、そうしたドメインモデリングに関する
Value Objectについて整理しよう - Software Transactional Memo
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
ドメイン固有型(値オブジェクト含む)を再考する - かとじゅんの技術日誌
Value Objectが盛り上がっているらしい。 Value Objectについて整理しよう - Software Transactional Memo Value Objectの説明に異論がないものの、主題はValue Object Obsessionのほうですよね。 こちらも聞いてみた。 fukabori.fm よい機会なので、よくわかっているつもりの、値オブジェクトというかドメイン固有型について再考してみよう。 それは値か属性か それはエンティティの全メンバーやデータベースの全列のために「顧客郵便番号」「送付先郵便番号」「事業所郵便番号」「契約日」などのクラス(メンバではなくクラス！)を定義して、immutableな振る舞いを強制する事を以てValue Objectであると言い張り、ドメイン知識の断片をそれぞれのクラスに書き散らして「高凝集になった」「型システムが守ってくれる」と喜
Implementing DDD, CQRS and Event Sourcing
This book explains and illustrates how to implement Domain-Driven Design, Command Query Responsibility Segregation and Event Sourcing. The goal is to build software that is behavior-rich, event-based, problem-centric, reactive, scalable and well-designed. Domain-Driven Design is a way to build software that focuses on the problem to solve and its associated knowledge areas. Command Query Responsib
GitHub - Sairyss/domain-driven-hexagon: Learn Domain-Driven Design, software architecture, design patterns, best practices. Code examples included
Check out my other repositories: Backend best practices - Best practices, tools and guidelines for backend development. System Design Patterns - list of topics and resources related to distributed systems, system design, microservices, scalability and performance, etc. Full Stack starter template - template for full stack applications based on TypeScript, React, Vite, ChakraUI, tRPC, Fastify, Pris
NTTコムウェア C+ | ITジャーナリストや現役書店員、編集者が選ぶ デジタル人材のためのブックレビュー 第5回：『エリック・エヴァンスのドメイン駆動設計』、『エンタープライズアプリケーションアーキテクチャパターン』
ソフトウェア開発において、使いやすいクラスやコンポーネントを設計するのは難しい。とりわけ大規模になると複雑怪奇になりやすい。そこで先人の良い知恵はないかと探してみると、「ドメイン駆動設計(Domain-driven design, DDD)」というソフトウェア分析・設計・開発技法があり、長きにわたって広く支持されていることがわかる。 本書は、このDDDに関する原典であり、原点とも言える。 DDDはある程度知っていたり、実際に使っていたりしても、本書を読んだことのない方も少なくないだろう。しかし、残念ながらそのような方には本書が語るDDDのエッセンスが伝わっていないことが多いのではないか、という懸念がある。 DDDにはさまざまな側面がある。現在は「第2部モデル駆動設計の構成要素」で紹介される一種のアーキテクチャ技法としての側面が広く知られている。だが、実はDDDの核心はそこにはない。 本書が
Rustでドメイン固有型を作る際のコツ
ドメイン固有型である、ドメインオブジェクトをRustで実装する際のコツみたいなものを簡単にまとめました。まぁ「ドメイン固有型」というと大袈裟なので、「独自に型を作る」を想定してもらえばよいと思います。OOPに慣れている人がハマりやすい点も簡単に言及しています。ご参考までに。 アドレス帳型を作る アドレス帳型を例にします。 先にコードを以下に示します。コード全体はGitHubリポジトリを参照してください。 #[derive(Debug, Clone)] pub struct AddressBook { name: String, entries: Vec<AddressEntry>, } impl Default for AddressBook { fn default() -> Self { Self { name: String::default(), entries: Vec::def
実践！ Typescript で DDD - マイクロサービス設計のすすめ - Leverages Tech Blog
対象読者 マイクロサービス化を検討しており、実際に作る場合の構成を参考にしたい。 ドメイン駆動設計について、基本的な用語の知識がある。 TypeScript を多少触ったことがある。理解がある。 はじめに こんにちは。エンジニアの吉村です。 現在、弊社が運営する teratail というサービスに携わっており、CakePHP で動作しているモノリシックな既存サービスをマイクロサービスに移行するというプロジェクトを進行中です。 この記事では、実務を通して得た知見として、マイクロサービス化によりどんな恩恵があるのか、具体的にどのような構成で実装をしているのかについてご紹介します。 TL;DR マイクロサービスのバックエンドサービスの実装に焦点を絞って、ドメイン駆動設計 + オニオンアーキテクチャをベースに設計をしました。 本記事では、具体的に「ユーザ新規登録処理」の実装をする場合を例にとり、実
Learning Domain-Driven Design
Read it now on the O’Reilly learning platform with a 10-day free trial. O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers. Building software is harder than ever. As a developer, you not only have to chase ever-changing technological trends but also need to understand the business domains behind the softwar
ドメインモデリングをするときに気をつけていること
ドメインモデリングをする上で個人的に気をつけている点をまとめました。 ドメインモデルとは 目的を達成するためだけに特化したモデルのこと ある目的を達成するために必要な情報（ドメイン知識[1]）の集合 仮にソフトウェアが存在しなくても現実世界でも通用する情報 技術的な関心ごとやソフトウェアがなければ成り立たない知識やルールはドメインの管轄外 ビジネスソフトウェアの場合 ビジネスを完遂する（目的を達成する）ために必要なルール（ドメイン知識）を表現したモノ ビジネスの決まり事を整理したモノ、と捉えてしまった方が理解しやすい 良いモデルとは 目的を達成できるモデル 目的を達成するために必要最小限の情報がまとまっている（凝集度が高い）モデル 属性として持っていたり、他のモデルと関係を持っていたり ドメインモデリングとは ある目的を達成するために必要な情報を抽象化して可視化する行為 情報を取捨選択、グ
DDDリファレンス 定義とパターン概要 (鋭意修正中, CC-BY)
Eric Evans "Domain-Driven Design Reference -- Definitions and Pattern Summaries" の日本語訳です。なかなか見直しと修正（推敲）が終わらないので、とりあえず公開してみます。 https://www.domainlanguage.com/ddd/reference/ ## 翻訳について パターン名については原則として『エリック・エヴァンスのドメイン駆動設計』（翔泳社）に合わせています。素晴らしい訳業に（元「DDD難民」の一人としても）記して感謝いたします。 ただし、「エンティティー」「メタファー」「レイヤー」「ファクトリー」など、末尾の音引きは省略せずに記することにしました。そのため、厳密には正確に同一ではありません（他にも「インタフェース」は「インターフェース」にしています）。ご了承ください。 ## 権利について
過大評価されるDDD（ドメイン駆動設計）
この記事は、著者の許可を得て配信しています。 Is Domain-driven Design overrated? ドメイン駆動設計（DDD）は、システムのモデリングと構築のための優れたガイドラインを提供する大変便利なアプローチですが、それ自体が目的ではなく、目的のための手段です。その概念は有効ですが、それを使うことだけに限定すると、その一方で多くのことを失うことになります。つまり、実際にはDDDの先にも人生があるということです。 最近、「DDD は過大評価されている」というクリックベイトなタイトルの記事を投稿したところ、皆様からかなり注目を集めました。今回の記事は、社内やソーシャルメディア（TwitterやHacker Newsなど）で受けたフィードバックを取り入れて、前回の記事に内容を加えたものとなっています。また、私の考えにもう少しニュアンスを加えたかったので、あまり過激なものにはし
ドメイン駆動設計で保守性をあげたリニューアル事例 〜 ショッピングクーポンの設計紹介
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ Yahoo!ショッピングクーポンチームの小倉です。 前回のフロントエンド技術刷新の話とは打って変わり、今回は2019年に行ったバックエンド技術刷新の話です。 刷新前のシステムはノンフレームワークPHPのモノリスでしたが、現在は主にJava/Spring Bootでマイクロサービス化しています。今回は、その中でもっとも仕様が複雑だったマイクロサービスにおいて、ドメイン駆動設計(Domain Driven Design:DDD)を実践した話をご紹介します。 ショッピングクーポンの自由度を知る みなさんは、ショッピングの商品が割引になるクーポンをご存じでしょうか？ 実は、クーポンには、ヤフーが予算をだして発行する「モールク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
イベントストーミング入門【ノーカット版】
Domain-Driven Design with Golang | Packt
SOLID: The Software Design and Architecture Handbook
Amazon.co.jp: セキュア・バイ・デザイン: 安全なソフトウェア設計 Compass Booksシリーズ: Dan Bergh Johnsson (著), Daniel Deogun (著), Daniel Sawano (著), 須田智之 (翻訳): Digital Ebook Purchas
