この記事は、LIFULL Advent Calendar 2024 21日目の記事になります。 はじめに LIFULLでは、技術負債解消のためにレガシーなコンポーネントをいわゆるCleanArchitecture(以降CA)に置き換えるという取り組みをやっています。 内製ソフトウェアアーキテクチャでレガシーシステムを刷新し技術的負債を削減するまでにやったこと クリーンアーキテクチャで構築したプロダクトが2年経過してみて現状どうなっているかを紹介 新卒エンジニアがリファクタを突貫したClean Architectureプロジェクトの舞台裏 CAはいくつかのレイヤに別れていますが、LIFULLではCAのEnitityをドメイン駆動設計(DDD)で言うところのドメインモデルで実装しています。 この記事は、前に読んでいた関数型ドメインモデリングの「型によるドメインモデリング」がこの実装に応用できる
2024年7月1日紙版発売 2024年7月1日電子版発売 増田亨，田中ひさてる，奥澤俊樹，中村充志，成瀬允宣，大西政徳 著 B5判／160ページ 定価2,200円（本体2,000円＋税10%） ISBN 978-4-297-14317-6 Gihyo Direct Amazon 楽天ブックス 丸善ジュンク堂書店 ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto この本の概要 ソフトウェア開発でドメイン駆動設計が注目されています。ソフトウェアデザイン誌で大変好評だった，ドメイン駆動設計特集の過去記事（2024年3月号，2023年2月号など）を再編集し，1冊にまとめました。ソフトウェアの設計は現在さまざまな視点で検討されており，開発の成功をいかに実現し達成するか重要になっています。本書は，ドメイン駆動
ドメイン駆動設計と関数型プログラミングを組み合わせることで、顧客満足度の向上、開発サイクルの短縮、無駄な作業の削減を実現できます。本書では、ビジネスドメインの例とF#のコードで、ビジネスに焦点を当てた、柔軟で高品質なソフトウェアを構築する方法を紹介します。たとえば、F#の型システムを使って複雑なドメインをモデル化し、読みやすいドキュメントにもなるコードを作成します。また、ビジネスルールをエンコードして「コンパイル時ユニットテスト」を作成することで、不正な状態を表現できないようにして潜在的なバグを排除します。関数型プログラミングの核となる原則を適用することで、実世界の要求をエレガントかつ簡潔にモデル化したソフトウェア設計を実現できます。 ドメイン駆動設計と関数型プログラミングを組み合わせることで、顧客満足度の向上、開発サイクルの短縮、無駄な作業の削減を実現できます。本書では、ビジネスドメイン
TypeScriptとドメイン駆動設計（DDD）を組み合わせ、APIを構築するハンズオンガイドです。この本では、DDDとは何かという基礎的なところからソフトウェア開発における戦略的設計、戦術的設計まで、包括的な知識を提供します。 戦略的設計では、ビジネスの要求に合わせたドメインモデルの設計をイベントストーミングを用いて行います。その後、戦術的設計では、具体的なコードの実装に関連するDDDの原則と実践を学びます。 TypeScriptを使ってコードを書きながら、DDDの概念を実際のプロジェクトに適用するヒントを紹介します。
最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスや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
Learn to write testable, flexible & maintainable code🔥 Write testable, flexible, maintainable TypeScript w/ Node.js🔥 Prevent unmaintainable code. Identify bad design and refactor towards a good one🔥 Use OOP + Domain modeling to tackle apps of any complexity🔥 Structure business logic away from dependencies, frameworks, tools🔥 Integrate Domain models into the heart of your application🔥 Use the
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く