サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
little-hands.hatenablog.com
株式会社ログラスの松岡(@little_hand_s)です。 最近、値オブジェクトに関して書かれているブログ記事を見ますが、 SNSなどにおいてDDDにおける値オブジェクトについて誤解されているような反応が見受けられました。 そこで、この記事では「DDDにおける値オブジェクトの位置付け」について解説し、具体的なモデル・コードを用いながら誤解を解いていきたいと思います。 なお、値オブジェクトに関する詳細な説明はここでは行いませんのでご了承下さい。 DDDの目的 まず最初に、DDDの目的について確認します。 DDDの目的は、モデリングを通じてソフトウェアの価値を大きくすることです。 これに関しては、こちらの記事で詳細に解説しているのでこちらをご覧ください。 ドメイン駆動設計は何を解決しようとしているのか - little hands' lab ここで大切なのは、モデルは一回のモデリングで完成形
記事の構成 アジャイルソフトウェア開発とは アジャイルマニフェストとは アジャイルマニフェストの問題 そこで、アジャイルの本質 by マーティンファウラー アジャイルソフトウェア開発とは? アジャイルソフトウェア開発とはなんでしょうか? 「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」 これが最もオリジナルな定義です。 なぜこんなややこしい言い回しをするのは後から説明します。 重要なことは、「アジャイル」という具体的な手法があるわけではないということです。 アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。 アジャイルの思想に則った開発手法として ・スクラム ・エクストリームプログラミング(XP) ・リーンスタ
DDDではよく「モデリングが重要だ!」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。 そんな方のために、本記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。 (本記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。) DDDの目的 DDDの目的から確認しましょう。 DDDの目的は2つ。 ①機能性を高めること これは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。 そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。 ②保守性を高めること これは、長期間開発しても機能拡張が容易であり
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
株式会社ログラスの松岡(@little_hand_s)です。 ドメイン層のオブジェクトを設計する際に、重要な基本方針があります。 ドメインモデルの知識を対応するオブジェクトに書く 常に正しいインスタンスしか存在させない この2つを守ると、非常に保守性の高いコードにすることができます。 以下、詳細に解説します。 ドメインモデルの知識を対応するオブジェクトに書く ドメイン知識(ルール/制約)を表現する実装を、ドメイン層のオブジェクトに寄せていきます。 この判断は、「ドメインモデル図に書かれた吹き出しの内容が、どの層で実装されているか」という基準に基づき行います。 この基準はコード設計の指針として非常に役立ちます。 設計の良し悪しというのはさまざまな基準があるため、レビューをしていてもいわゆる「俺の考えた最強の設計」同士が戦ってしまうことがあります。 しかし、「ドメイン知識はドメイン層に書く」と
本記事はドメイン駆動設計(DDD) Advent Calendar 2021の13日目の記事です。 エンティティとイミュータブル性 オブジェクトをイミュータブル、つまり内部状態を変えない実装にすることで可読性やマルチスレッド対応性が向上することがあります。 エンティティはモデリング上の定義はミュータブルなものですが、実装方法をイミュータブルにすることは可能です。 (DDDでは、エンティティはミュータブルもしくはイミュータブル、値オブジェクトは必ずイミュータブルという定義です。詳しくはこちら) DDD基礎解説:Entity、ValueObjectってなんなんだ - little hands' lab 本記事ではエンティティをイミュータブルな実装にするサンプルコードと合わせて、イミュータブルにした場合の旨みを感じられるコードを紹介します。 イミュータブルなエンティティ実装の例 エンティティをイ
面倒臭いオブジェクト詰め替え オニオンアーキテクチャ、クリーンアーキテクチャなどの階層化されたアーキテクチャを使用する際、レイヤーの境界でオブジェクトの値を詰め替える必要性が発生します。 オブジェクトを詰め替えることでレイヤーの依存関係を断ち切り、一度書いた後の保守性を高めることに大きく貢献するのですが、筆者の観測範囲では単調作業に感じるせいかかなり嫌われる傾向があるように感じます。 そして、そのような詰替を嫌うばかりにオブジェクト詰め替えをやめてしまうこともありますが、それは非常にもったいないことです!! なぜなら、「初期実装の数分の重要性 <<<< その後の保守性の重要性」だからです。 なので、できればきちんと詰め替えしてレイヤーの依存関係を保って欲しい、ということで、そのために詰め替えが超簡単にできる方法をご紹介します。 まずはデモご覧ください。 class Entity( val
DDD Community Jpは、Discordというチャットツールを利用しているオンラインコミュニティです。 チャットで質問を行うチャンネルや、ボイスチャットで開催されるオンライン勉強会などがあります。 Discord参加用リンク また、オフラインでも不定期でミートアップなどのイベントも不定期で開催しています。 connpassのコミュニティページでメンバーになっていただくと、イベント開催時に通知を受け取ることができます。 connpassのコミュニティページ
株式会社ログラスの松岡です。 本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
Object-Oriented Conference 2020で登壇させていただきました。 その際の発表資料です。 発表資料 DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか from Koichiro Matsuoka www.slideshare.net 本章の内容は技術書典8(2020/3/1)で頒布予定の「ドメイン駆動設計 モデリング/実装ガイド」の1,2章の内容になります。 全部で11章仕立てです、興味お持ちいただけたらお買い求めください。 受け取りは技術書典以降になりますが、それでもよろしければboothで予約可能です。 little-hands.booth.pm 【2021/10/30新刊】 DDD解説書の新刊を執筆しました。 重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具体的なサンプルコー
チームで議論するときに常に心がけているのが、「問題解決の5階層」です。 この図で重要なことは、 下の階層で認識が一致していないと、上の階層では絶対認識があわない ということです。 「あれ、議論が噛み合っていないな?」と思ったら、この階層に照らし合わせて認識があっていないことがないか確認しましょう。 問題認識のすれ違い 例えばこのように問題の認識の違いがあったとします。 なぜ違いが生まれたのでしょうか? コードの保守性に関する経験や、スキルの違い?と考えてしまうかもしれません。 でも実際は、こうでした この話題に出てきたときの、認識していたコードが違うものだったのです。 このような場合、事象の認識を合わせて初めて、問題の認識を合わせることができます。 このようなケースは非常に多いです。 普段一緒の空間で仕事をしていても、個人作業をしている時間は多いほど、人によって見えているもの、体験したこと
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
WEB+DB PRESS Vol.113の特集として、「体験 ドメイン駆動設計 - モデリングから実装までを一気に制覇」を執筆しました。ボトムアップドメイン駆動設の@nrslibさんとの共著です。 抽象的な解説だけでなく、実際にモデリングから実装まで行うサンプルがある こと、ドメインモデル図、サンプルコードそれぞれ4段階に分かれて改善の過程が追えるようになっている ことが特徴です。 DDDでは抽象的な議論に終始しがちなところ、具体的な事例を用いて目的や効果を理解してもらえる構成を心がけました。 構成 1章 なぜいまドメイン駆動設計か - 仕様がわかり、変更容易なコードへ 担当: @nrslibさん 「結局DDDって何がしたいの?」ということを理解できるように、従来の開発手法の問題点、ドメイン駆動設計による解決法を示します。 2章 ドメインモデリング - 現場の知識を抽出し、問題解決力の高い
DDD関するトピックを中心にオンライン研修、チャットサポートをご要望ベースで実施しております。ご相談は @little_hand_sのDM、もしくはお問い合わせフォームまでお願いいたします。 DDD導入サポート ①ライブモデリング、ライブコーディング研修(zoom開催) ご相談いただく方の現場の題材でモデリングから実装までを簡易的に一通り行い、DDDの全体像を把握していただくことができます。 モデリング、コーディングそれぞれ所要時間は約2時間です。片方のみ実施も可能です。 DDDの基礎知識については、事前に座学コンテンツはこちらの動画を見ていただいています。 DDDオンライン勉強会 #1 「モデリング/実装入門」 - YouTube こちらで基礎的な認識は揃えていただけるので、 直接お話しする時はより具体的な内容をできるようにしています。 アンケートで、よかった点として以下のようなご意見を
DDD-Community-Jpとして久々のイベントを開催しました! ddd-community-jp.connpass.com 今回は 聞くだけではなくコミュニケーションをたくさんとってもらいたい! というのを重視して、今回は会議室ではなくレストランで飲み放題、の開催としました。 そのため発表時間はかなり圧縮して5分としたのですが、発表いただいた7人の方々皆さまかなり濃い発表で、7分には収まらない情報量でした。 どれもじっくり読み返したい内容でしたので、資料提供いただきまとめさせていただきました。 LT資料 DDD以前とDDD以降、そしてRDRAへ @carotene4035さん google スライドリンク DDD導入に踏み切れない方へ送る 2層+CQSアーキテクチャ @hirodragon112さん www.youtube.com DDDなら概念層だけ触っていたい! with Cod
Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD! コラボカンファレンス に登壇させていただいたのでで、その際の資料です。 また、当日sli.doでたくさんのご質問をいただいたので、まとめてお答えします。 発表資料 DDDのモデリングとは何なのか、 そしてどうコードに落とすのか from Koichiro Matsuoka www.slideshare.net もっと詳しく知りたい方は この発表資料の内容を、さらに詳しく解説した書籍を出しました! little-hands.booth.pm 初めてDDDを学ぶ方、もしくは実際に着手して難しさにぶつかっている方向けの書籍になっています。 迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。 この本の「第2章
「実践ドメイン駆動設計」から学ぶDDDの実装入門 DDD関連の新刊が出たのでレビューします。 「実践ドメイン駆動」(以下IDDD)という書籍を元に、それを読み解くための書籍、という位置付けの珍しい書籍です。確かにIDDD本は分厚くて難解ですからね。 CodeZineの人気連載を書籍化。 エリック・エヴァンスのドメイン駆動設計(DDD)の考え方を、実際に導入するためには、それぞれの開発現場に合わせて、さらに具体的に噛み砕く必要があります。 そこで本書は、このDDDの考え方を実践に落とし込んだ書籍「実践ドメイン駆動設計」の構成に沿って、現代の開発現場において重要な部分にフォーカスし、DDD実装のノウハウを解説しました。図版を多く用い、DDD初心者にも分かりやすく解説しています。 「DDDという言葉を知っているものの、全容を理解できていない」「DDDを自分たちの現場に導入したいが、何から始めたら
DDDの文脈の中で、 「ドメイン知識とユースケース(≒アプリケーションの知識)は何が違うのか?」 という疑問がよく持たれます。 この記事ではその違いを説明し、DDDのコードにどう反映するかを書きます。 あるToDoアプリの仕様 事例として、ToDoアプリの話をします。 「仕様を決める」と言ったとき、以下のように箇条書きで決めることがあると思います。(Jiraのようなチケット管理システムのチケット詳細として書いたりしますよね) ユーザー登録、非活性化ができる メールアドレスは重複登録できない タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる タスクは3回までしか延期ができない 非活性化されていないユーザーにアサインができる タスクを完了、アサインするとタスクレポートが作成される これはいわゆる「ビジネスロジック」と呼ばれて、3層レイヤーのアーキテクチャではBusine
genbade-ddd.connpass.com こちらのイベントに参加してきました。 タイトルに「レガシーをぶっつぶせ」とあった効果か、基本レガシーに立ち向かった実体験ベースの具体的な、泥臭い話が多くて非常に楽しかったです。 DDD周りって結構抽象的な話に終始してしまうことが多いので、これほど具体的な話が集まったイベントはすごく貴重だったと思います。人数も相当集まっており相当好評だったようでまたやりたい、とクロージングで話されていたので、また次回に期待したいです。 モデリングハンズオン その中で、「DDDモデリングハンズオン」というコンテンツがあり、モデリングしながらドライバーの方がライブでコードを書いていただくというとても良いコンテンツがあったので参加してきました。 そこでは携帯の月額プランをお題にモデリングをされていました。 そこで参加した内容が時間内に終わらなかったこともあり、自分
今日の記事では、 「こんなコードを書くとあとでびっくりするからやめた方がいいよ!」 という事例をご紹介します。 問題のあるコード 以下のようなタスクEntityがあったとします。 コンストラクタで生成時のルールを,doneメソッドで状態遷移のルールを表現しています。 public enum TaskStatus { UNDONE, DONE } class Task { private String taskId; private String name; private TaskStatus taskStatus; private LocalDate dueDate; public Task(String name, LocalDate dueDate) { this.name = name; this.dueDate = dueDate; // idは初期化時にUUIDで生成される t
Mob Programming体験会 with Chris Lucianというイベントに参加してきました。 Chrisさんは最近のモブプロブームの発端となっている(という認識)Hunter Industries社の方で、Regional Scrum Gathering Tokyo 2019の基調講演に登壇された方です。モブプロを実際に長年実践されているされているお話を聞ける機会はなかなかない!ということで勢い勇んで参加してまいりました。 モブプロに関する紹介と、Regional Scrum Gathering Tokyo 2019(以下RSGT)の"Learning to Experiment"というタイトルの講演をこちらの会でも再演いただきました。 その中で、参考になった点、心に残った点をご紹介したいと思います。 Hunter Industriesの具体的な事例 Hunter Indus
この記事はドメイン駆動設計 #2 Advent Calendar 2018の16日目の記事です。 DDD(ドメイン駆動設計)とは何なのか そもそもDDDってなんなの?ということをちょくちょく聞かれます。 一言で言うと、「開発手法の一種です」ですが、それだと「ふ〜ん」で終わってしまうので、もう少し興味を持ってもらえる回答を考えます。 まず、開発してて何に困るのかがわからないと思うので、そこから説明をします。 非エンジニア向けの説明 開発手法にも色々あり、行き当たりばったりに作ると以下のような問題に突き当たる、ということがよくあります。 実際の業務をきちんと理解しないで作ったら、 リリースしてもあんまり使われなかったり不評なものができる きちんと整理されてないプログラムを書いたら、 あとから修正するのがどんどん大変になる DDDは、このの2個とも解決しよう、ということで生まれた設計・開発手法な
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの?」 という
はじめに DDDの実装パターンとして、エンティティと値オブジェクトというものがあります。 ドメイン駆動一般に複雑な抽象論が多い中で、コードに近く一番イメージがつきやすいコード事例として出てくるため、ここだけは何となくわかるぞ!という方もいらっしゃるのではないでしょうか。 今日はこちらの概要とそれぞれの使い道について書きたいと思います。 先にざっくりイメージ図をお伝えすると、こういう図を使って解説します。 何の目的で作るのか? ドメイン駆動設計は何を解決しようとしているのか こちらの記事で、ドメイン駆動設計のアプローチは以下の2ステップがあるということを書きました。 ドメインの問題を解決するための抽象的なモデルを作る. モデルをソフトウェア(コード)に落とし込む ※ ドメイン=ソフトウェアを適用して問題解決しようとする領域 DDDでは、このStep2の モデルをコードで表現するためのパターン
ドメイン駆動設計の定義についてEric Evansはなんと言っているのか の記事の中で、EricEvansのドメイン駆動の定義を引用して以下のように和訳しました。 ドメインの中核となる複雑さと機会に焦点を当てる ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する 明示的にそれらのモデルを表現するソフトウェアを書く 境界付けられたコンテキストの中のユビキタス言語で話す この中で、重要なポイントが明示されていませんでした。 定義にある4点のようなことを、なぜやる必要があるのか? ということです。 つまり、ドメイン駆動設計は、一体何を解決しようとしているのでしょうか? ドメイン駆動設計は何を解決しようとしているのか DDDはソフトウェア開発手法の一つです。 なのでまず、ソフトウェア開発の目的について考えてみましょう。 人々はなぜ、ソフトウェアを開発するのでしょうか? それは、
Dependency Injectionとは Dependency Injectionを日本語でなんと訳しますか? 大体「依存性の注入」と訳されることが多いですよね。 確かに直訳するとその通りなのですが、実際に行っていることを表していない、非常にミスリーディングな誤訳だと思います。 依存性を注入する、と言われると、まるで新しい依存性が増えるような印象を受けますが、実際はそうではありません。 googleの言語設定を英語にして検索してみると、英語版Wikipediaがトップで出てきて以下のように説明されています。 In software engineering, dependency injection is a technique whereby one object (or static method) supplies the dependencies of another objec
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か - little hands' lab ドメイン駆動 + オニオンアーキテクチャ概略 - little hands' lab これらの記事で書いた通り、私はDDDのレイヤードアーキテクチャを決める際にオニオンアーキテクチャの用語を使っています。これまで色々な人に説明してきて、理解につまづきやすいポイントとしてレイヤの責務の話があったので、そこについて解説します。 一発で伝わりにくい(と思っている)定義 Onion Architecture Is Interesting - DZone Java こちらの記事で書かれている各レイヤの説明 Domain Layer Domain Model layer, where our entities and classes closely related to them e.g.
はじめに 設計の善し悪しについて日々色々と議論することはあると思いますが、「良い設計」「悪い設計」について明文化した定義はあるでしょうか。おそらく、各々の頭の中にぼんやりと、もしくは断片的にはあるものの、チームで良し悪しについて定義まですることはあまり多くないのではないでしょうか。 各プロジェクトで議論することには価値があると思いますが、一つ基準になるものがあると議論しやすいと思います。そこで一つ、オブジェクト指向の原則を提唱したUncle BobことRobert Cecil Martinが提唱している「悪い設計」の定義について参照してみましょう。 Uncle Bobについて そのまえに、Uncle Bobについて紹介します。 Robert Cecil Martin(wikipedia) 有名な「クリーンコード」の著者、と言えばわかりやすいでしょう。そのほかにも、オブジェクト指向の設計原則
次のページ
このページを最初にブックマークしてみませんか?
『little hands' lab』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く