ドメイン駆動設計と関数型プログラミングを組み合わせることで、顧客満足度の向上、開発サイクルの短縮、無駄な作業の削減を実現できます。本書では、ビジネスドメインの例とF#のコードで、ビジネスに焦点を当てた、柔軟で高品質なソフトウェアを構築する方法を紹介します。たとえば、F#の型システムを使って複雑なドメインをモデル化し、読みやすいドキュメントにもなるコードを作成します。また、ビジネスルールをエンコードして「コンパイル時ユニットテスト」を作成することで、不正な状態を表現できないようにして潜在的なバグを排除します。関数型プログラミングの核となる原則を適用することで、実世界の要求をエレガントかつ簡潔にモデル化したソフトウェア設計を実現できます。 ドメイン駆動設計と関数型プログラミングを組み合わせることで、顧客満足度の向上、開発サイクルの短縮、無駄な作業の削減を実現できます。本書では、ビジネスドメイン
TypeScriptとドメイン駆動設計(DDD)を組み合わせ、APIを構築するハンズオンガイドです。この本では、DDDとは何かという基礎的なところからソフトウェア開発における戦略的設計、戦術的設計まで、包括的な知識を提供します。 戦略的設計では、ビジネスの要求に合わせたドメインモデルの設計をイベントストーミングを用いて行います。その後、戦術的設計では、具体的なコードの実装に関連するDDDの原則と実践を学びます。 TypeScriptを使ってコードを書きながら、DDDの概念を実際のプロジェクトに適用するヒントを紹介します。
フロントエンドの複雑さに立ち向かう 〜 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の実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います! 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ
sumirenです。 経営管理(事業計画作成、財務Modeling)SaaS「Zaimo.ai」を開発するZaimo株式会社で、技術顧問としてドメインモデリングや組織設計のアドバイザリを行っています。 Zaimo.aiでは、スケール後もドメインモデリングを事業全体で活用できるよう、創業間もないフェーズからドメインモデリングを組織的に活用するカルチャーづくりに励んでいます。 ドメインモデリングというと、DDDのような重厚なプロセスを想像される方が多いかと思います。同時に、技術が目的と化している熱狂的DDDファンも少なくないことから、ドメインモデルというワード自体に拒否反応を覚える方もいると思います。 しかし、ドメインモデリングはもっと手軽に使えるものであり、エンジニアリングのみならず、事業全体にインパクトをもたらしうるものと筆者は考えています。この記事では、そうしたドメインモデリングに関する
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であると言い張り、ドメイン知識の断片をそれぞれのクラスに書き散らして「高凝集になった」「型システムが守ってくれる」と喜
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
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
ソフトウェア開発において、使いやすいクラスやコンポーネントを設計するのは難しい。とりわけ大規模になると複雑怪奇になりやすい。そこで先人の良い知恵はないかと探してみると、「ドメイン駆動設計(Domain-driven design, DDD)」というソフトウェア分析・設計・開発技法があり、長きにわたって広く支持されていることがわかる。 本書は、このDDDに関する原典であり、原点とも言える。 DDDはある程度知っていたり、実際に使っていたりしても、本書を読んだことのない方も少なくないだろう。しかし、残念ながらそのような方には本書が語るDDDのエッセンスが伝わっていないことが多いのではないか、という懸念がある。 DDDにはさまざまな側面がある。現在は「第2部モデル駆動設計の構成要素」で紹介される一種のアーキテクチャ技法としての側面が広く知られている。だが、実はDDDの核心はそこにはない。 本書が
ドメイン固有型である、ドメインオブジェクトを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 を多少触ったことがある。理解がある。 はじめに こんにちは。エンジニアの吉村です。 現在、弊社が運営する teratail というサービスに携わっており、CakePHP で動作しているモノリシックな既存サービスをマイクロサービスに移行するというプロジェクトを進行中です。 この記事では、実務を通して得た知見として、マイクロサービス化によりどんな恩恵があるのか、具体的にどのような構成で実装をしているのかについてご紹介します。 TL;DR マイクロサービスのバックエンドサービスの実装に焦点を絞って、ドメイン駆動設計 + オニオンアーキテクチャをベースに設計をしました。 本記事では、具体的に「ユーザ新規登録処理」の実装をする場合を例にとり、実
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])の集合 仮にソフトウェアが存在しなくても現実世界でも通用する情報 技術的な関心ごとやソフトウェアがなければ成り立たない知識やルールはドメインの管轄外 ビジネスソフトウェアの場合 ビジネスを完遂する(目的を達成する)ために必要なルール(ドメイン知識)を表現したモノ ビジネスの決まり事を整理したモノ、と捉えてしまった方が理解しやすい 良いモデルとは 目的を達成できるモデル 目的を達成するために必要最小限の情報がまとまっている(凝集度が高い)モデル 属性として持っていたり、他のモデルと関係を持っていたり ドメインモデリングとは ある目的を達成するために必要な情報を抽象化して可視化する行為 情報を取捨選択、グ
Eric Evans "Domain-Driven Design Reference -- Definitions and Pattern Summaries" の日本語訳です。なかなか見直しと修正(推敲)が終わらないので、とりあえず公開してみます。 https://www.domainlanguage.com/ddd/reference/ ## 翻訳について パターン名については原則として『エリック・エヴァンスのドメイン駆動設計』(翔泳社)に合わせています。素晴らしい訳業に(元「DDD難民」の一人としても)記して感謝いたします。 ただし、「エンティティー」「メタファー」「レイヤー」「ファクトリー」など、末尾の音引きは省略せずに記することにしました。そのため、厳密には正確に同一ではありません(他にも「インタフェース」は「インターフェース」にしています)。ご了承ください。 ## 権利について
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く