ドメイン駆動設計(DDD)を整理
またクラスを利用していないため、オブジェクト指向の特性「継承」「カプセル化」「ポリモーフィズム」は利用していません。この部分が厳密なドメイン駆動設計(DDD)のニュアンスと異なるので「風味」という言葉を使っています。 全体概要と用語の整理 まず初めにドメイン駆動設計の全体の概要と出てくる用語について紹介します。 自分は言葉を理解しないとコードの理解に落とし込めなかったので詳しく解説をしていきます。 各用語の具体的な実装は後の章で紹介します。 すべての用語において理解しやすいように「ユーザー管理システムを実装する」例を用いて解説を入れています。(解説の都合で書籍とは異なる例を採用しています) ドメイン駆動設計とは ドメイン駆動設計はその名の通り、「ドメインの知識」に焦点をあてた設計方法 「ドメイン」とは、ソフトウェア開発におけるプログラムを適応する対象となる領域 ドメインについて ドメイン駆
フロントエンドの複雑さに立ち向かう 〜DDDとClean Architectureを携えて〜 | さくらのナレッジ
自己紹介 さくらインターネットではシニアフロントエンドエンジニアをやっています。代表作は「NES.css」というファミコン風CSSフレームワークで、エイプリルフールには「さくらのINFRA WARS」というゲームの企画開発をしていました。 話さないこと 本記事ではソフトウェア設計ということで、以下の設計・アーキテクチャに関しては話す予定はありません。コンポーネント設計や CSS 設計に関しては過去に記事やスライドを公開していますので、気になる方はそちらを参考にしていただければと思います。 コンポーネント設計 加速するコンポーネント設計入門 / Component Design as an Accelerator コンポーネント指向時代のmargin戦略 / Rethinking the relationship between Components and Margins CSS設計 OO
実践クリーンアーキテクチャ with Java
この記事について こちらの記事はクリーンアーキテクチャの Java 実装による解説記事です。 MVC フレームワークに組み込むために一部変更している部分もあります。 それをふまえてご覧ください。 講演内容が @IT さまに記事にしていただけました。 あわせてご参照ください。 https://www.atmarkit.co.jp/ait/articles/1907/08/news002.html クリーンアーキテクチャよりも軽量で無理なく導入しやすいアプリケーションアーキテクチャパターンを考案しました。 https://nrslib.com/adop/ スライド JJUG CCC 2019 Spring での発表資料です。 この発表をするにあたって記事を書くことにしました。 YouTube YouTube でこちらの解説を行いました。 その他解説もしています。もしよろしければチャンネル登録を
実践クリーンアーキテクチャ │ nrslib
YouTube での解説 YouTube にて Java コードをベースに解説を行いました。 コードの雰囲気は C# とほとんど同じなので参考になるかと思います。 もしよければご覧ください。 Java コードの記事リンク：https://nrslib.com/clean-architecture-with-java/ その他解説もしています。もしよろしければチャンネル登録をお願いいたします。 Qiita 版 Qiita に CUI や GUI 向けのクリーンアーキテクチャの記事を書きました。 ボブおじさんのクラス図を模したものです。 Web とはまた異なった実装になるので、もしよければ合わせてご参照ください。 https://qiita.com/nrslib/items/a5f902c4defc83bd46b8 さらに PHP の Laravel 版も作ってみました。 https://qi
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
【SOLID原則】依存性逆転の原則 - DIP
SOLID原則とは、ソフトウェア設計の5つの原則の頭字語を取ったものです。ソフトウェアをより理解しやすく、より柔軟に、よりメンテナナンス性の高いものにするために考案されました。 単一責任の原則（Single Responsibility Principle） オープン・クローズドの原則（Open/closed principle） リスコフの置換原則（Liskov substitution principle） インターフェース分離の原則（Interface segregation principle） 依存性逆転の原則（Dependency inversion principle） 今回はSOLID原則のひとつ、依存性逆転の原則についてです。 TSで書いたサンプルコードを載せますが、あくまで依存性逆転の原則を理解するためのサンプルとして見て頂ければと思います。 依存性逆転の原則 依存性逆
【DDD】値オブジェクト - Value Object
値オブジェクトとは 業務で使う単位で値のルールをクラスとして表現したものです。例えば年齢は通常、number型のようなプリミティブな値で表現されることが多いですが、値オブジェクトではarg型として業務で扱う単位の型で表現します。 書籍「実践ドメイン駆動設計」[1]では、値オブジェクトの特徴について、このように書かれています。 ドメイン内の何かを計測したり定量化したり説明したりする 状態を不変に保つことができる 関連する属性を不可欠な単位として組み合わせることで、概念的な統一体を形成する 計測値や説明が変わったときには、全体を完全に置き換えられる 値が等しいかどうかを、他と比較できる 協力関係にあるその他の概念に「副作用のない振る舞い」を提供する 次のサンプルコードを見て、特徴と照らし合わせながら確認していきます。 /** * 預けているお金の操作を行うクラス */ class Balanc
軽量DDDでもやったほうがいい理由、けどやらない理由 - Qiita
記事のターゲット DDD（ドメイン駆動設計）に興味がある人 DDD系の本読んだけど掴み所がないなと思った人 戦術的DDD（軽量DDD）を取り入れようとしている人 戦術的DDD（軽量DDD）とは ドメイン駆動設計の文脈で語られる技術的要素のみを取り入れる設計手法です Google検索などで引っかかる情報の多くは技術的要素の内容です （過去記事でも部分的にまとめていますので興味があれば是非） レイヤードアーキテクチャの視点 ValueObjectという考え方 Serviceクラスの意義と勘所 「技術的要素のみ？DDDってそういうものじゃないの？」と思ったかも知れません DDDの本質は問題解決のための手法なので、技術的要素はその一つでしかないのです 完璧じゃなくても軽量だけでもいい DDDに関わらず、プログラミング含めたテクノロジーも問題解決のツールの一つです そのツールが万能になるとき、問題は
DDDオンライン勉強会 #1 「モデリング/実装入門」
0:00:00 開始待ち 0:19:50 講義 1:36:50 ライブコーディング 2:11:45 Q&A 【執筆書籍】 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 はじめてDDDを学ぶ方、実際に着手して「難しい！」と感じている方を対象とした、DDDについての解説書です。実際の質問を元にしたQ&Aもあります。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 DDDに関して頻出の質問に、多くのサンプルコードを交えて回答した解説書です。 モデリング、集約の実装、テストについても具体例を交えて解説しています。 サンプルコード https://github.com/little-hands/ddd-task-managem
Laravel - 『ドメイン駆動設計入門』してみて Clean な世界を垣間見た話し - Qiita
要約 / inb4 tl;dr 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んで DDDの初歩 について学んだら、以前から気になっていた Clean Architecture についての記事も理解しやすくなった。 Laravelで実践クリーンアーキテクチャ - Qiita Laravelでクリーンアーキテクチャ - Qiita 前回の記事で実装したディレクトリ構成を改めて見直した。 前回の記事：Laravel - 『ドメイン駆動設計入門』を読んで Laravel を使って実装してみた - Qiita それっぽい構成が出来たので、今後実装する時のために思考を整理してみた。 はじめに 前回の記事 でも書いたのですが、2020年2月9-11日に開催された PHPerKaigi2020 に参加してきました。 PHPerKaigi 2020 ここで以下の本を知り、DD
Software Architecture - DDD と アーキテクチャ にまつわるエトセトラ - Qiita
要約 / inb4 tl;dr DDD（ドメイン駆動設計）について調べ始めたら、解説記事でお腹いっぱいになった。 更に、一緒に語られるアーキテクチャも整理したい欲が出てきた。 Layered Architecture Layered Architecture with DIP (Dependency inversion principle) Hexagonal Architecture Onion Architecture Clean Architecture こういった経緯で、元になった書籍や記事をまとめてみた。 ちょっとしたまとめも書いた はじめに 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んで DDD入門をしてみて、ボトムアップで作り上げるときの アーキテクチャ に興味が湧き、今後、調べていくに当たって最初に見るべきであろう情報をまとめてみました。
重要なのは「先を見据えた柔軟なアーキテクチャ構成」 3チームの並列開発を実現したモジュラモノリスの採用
LINEのサービス開発拠点の1つである「LINE KYOTO」のオフィスで開催する技術イベント「LINE KYOTO 交流会 ～3年ぶりのおこしやす～」。ここで京都開発室K2チームの古田氏が登壇。出前館における加盟店プロダクトのリプレイスについて話します。 古田氏の自己紹介 古田大志氏：では「出前館マイクロサービスにおける加盟店管理画面のBFFアーキテクチャ」というお題で発表します。古田大志と申します。よろしくお願いします。 まず自己紹介を軽くします。LINEでサーバーサイドエンジニアをやっていて、主な技術領域はJavaやKotlinやSpring Boot、最近だとTerraformを触ったりしています。（スライドを示して）GitHubのアカウントはこんな感じになってます。 僕はもともと競技プログラミングをしていて、CSの分野に興味を持ち、Webを触り始めた背景があります。 現状、LIN
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
どのツールを選択するかではなく何を解決するかが大事 マイクロサービスの“光”と“闇”
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここでVMware Tanzu Labsの濱平氏が登壇し、「マイクロサービスの光と闇」をテーマにマイクロサービスの実態とtipsを紹介しました。 「マイクロサービスの光と闇」の概要 濱平紗穂氏（以下、濱平）：みなさんこんにちは。このセッションでは「マイクロサービスの光と闇」と題して、マイクロサービスを取り囲む実体、考慮しておくと有益なtipsを紹介したいと思います。さっそくですが、マイクロサービスの定義について、認識を合わせておきたいと思います。 マイクロサービスは実装戦略、ストラテジーの1つのツールだと考えています。ツールは、常に良い面と悪い面が同時に存在しています。そのため、選択時にこれらを理解する必要があります。そこで今回のスコープは、マイクロサ
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab
DDD連載記事 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっつきやすい」と考えるアーキテクチャを紹介します。 前提としてですが、完全に個人的な経験に基づく私見になります。 DDDの理論の中で、アーキテクチャに関しては「エリック・エヴァンスのドメイン駆動開発」(以下原典)と実践ドメイン駆動開発(以下IDDD)とでも異なったものが紹介されており、唯一の正解
![ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed125204d89ae253a4ab2a6c711eff21748ee9c7/height=288;version=1;width=512/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F30489%2F81fcfd95-2ce1-82a8-db69-8618338a5f22.png)
CQRS実践入門 [ドメイン駆動設計] - little hands' lab
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
![CQRS実践入門 [ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/fe5018ad772252621db406116ce62131478fb6b1/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20191202%2F20191202061944.png)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
成瀬さん直伝！2024年最新アーキテクチャトレンドとユースケースを徹底解説 (2024/02/14 12:00〜)
はじめに｜【DDD入門】TypeScript × ドメイン駆動設計ハンズオン
)
ドメイン駆動設計(DDD) カテゴリーの記事一覧 - little hands' lab