peketaminのブックマーク - はてなブックマーク

DDDにおける値オブジェクトの位置付け(モデルとコード事例あり)[ドメイン駆動設計] - little hands' lab

株式会社ログラスの松岡(@little_hand_s)です。最近、値オブジェクトに関して書かれているブログ記事を見ますが、 SNSなどにおいてDDDにおける値オブジェクトについて誤解されているような反応が見受けられました。そこで、この記事では「DDDにおける値オブジェクトの位置付け」について解説し、具体的なモデル・コードを用いながら誤解を解いていきたいと思います。なお、値オブジェクトに関する詳細な説明はここでは行いませんのでご了承下さい。 DDDの目的まず最初に、DDDの目的について確認します。 DDDの目的は、モデリングを通じてソフトウェアの価値を大きくすることです。これに関しては、こちらの記事で詳細に解説しているのでこちらをご覧ください。ドメイン駆動設計は何を解決しようとしているのか - little hands' lab ここで大切なのは、モデルは一回のモデリングで完成形

peketamin 2022/08/15

リンク

アジャイル迷子のための「アジャイルの本質」。あとDDDとのつながり - little hands' lab

記事の構成アジャイルソフトウェア開発とはアジャイルマニフェストとはアジャイルマニフェストの問題そこで、アジャイルの本質 by マーティンファウラーアジャイルソフトウェア開発とは？アジャイルソフトウェア開発とはなんでしょうか？「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」これが最もオリジナルな定義です。なぜこんなややこしい言い回しをするのは後から説明します。重要なことは、「アジャイル」という具体的な手法があるわけではないということです。アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。アジャイルの思想に則った開発手法として・スクラム・エクストリームプログラミング(XP) ・リーンスタ

peketamin 2022/06/27

リンク

簡単にできるDDDのモデリング - ドメイン駆動設計 - little hands' lab

DDDではよく「モデリングが重要だ！」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。そんな方のために、本記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。 (本記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。) DDDの目的 DDDの目的から確認しましょう。 DDDの目的は2つ。 ①機能性を高めることこれは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。 ②保守性を高めることこれは、長期間開発しても機能拡張が容易であり

peketamin 2022/06/01

リンク

設計/コードレビューで"常に"心がけるポイント - little hands' lab

株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatena blog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか高凝集クラスに関してメソッドに関して低結合 ③ユニットテストを書きやすいか合言葉筆者執筆書籍現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。

peketamin 2022/01/28

リンク

DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab

株式会社ログラスの松岡です。本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。実装方法は、主に以下の3つに分かれます。ユースケースで複数集約に更新をかけるドメインサービスを使用するドメインイベントを使用する目次目次集約の定義について題材とする事例実装方法1. ユースケースで複数集約を更新するメリット・デメリット実装方法2. ドメインサービスを使用するメリット・デメリット改善案実装方法3. ドメインイベントを使用するドメインイベント作成に制約をつけるメリット・デメリットまとめ集約の定義について詳しく知りたい方は現場での導入で困ったら集約の定義について集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p

peketamin 2021/03/08

リンク

ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab

この記事はドメイン駆動設計 Advent Calendarの記事です。今年の9月にログラスというスタートアップに転職しました。ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。入社時の状況なにをしたかテストの話が多い理由実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにしたレイヤーごとのオブジェクトの依存関係を整理レイヤーごとのテスト方針クラス名の重要性参照実装を作成した「責務」と「テスト」の重要性

peketamin 2020/12/22

リンク

JJUG2017fall 「DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話」 - little hands' lab

発表資料 DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話 from Koichiro Matsuoka www.slideshare.net twitterの反応 togetter.com CQRSの参考資料 CQRS | Microsoft Docs CQRS - Martin Fowler 英語ですが、CQRSの概要についてものすごくわかりやすく書いてあります。英語頑張って読んだほうが日本語で断片的な資料をたどるより結果的にわかりやすいと思います・・・！イベントソーシングの参考資料 Event sourcing in practice 今まで見た中で圧倒的にわかりやすいイベントソーシングの資料です。英語ですが平易なので読みやすいと思います。当ブログ発表資料関連の記事 little-hands.hatena blog.com writeモデル実装の意図を詳

peketamin 2020/03/30

CQRS
DDD

リンク

非エンジニアの方に「DDDって何なの？」と聞かれたときの説明[ドメイン駆動設計] - little hands' lab

この記事はドメイン駆動設計 #2 Advent Calendar 2018の16日目の記事です。 DDD(ドメイン駆動設計)とは何なのかそもそもDDDってなんなの？ということをちょくちょく聞かれます。一言で言うと、「開発手法の一種です」ですが、それだと「ふ〜ん」で終わってしまうので、もう少し興味を持ってもらえる回答を考えます。まず、開発してて何に困るのかがわからないと思うので、そこから説明をします。非エンジニア向けの説明開発手法にも色々あり、行き当たりばったりに作ると以下のような問題に突き当たる、ということがよくあります。実際の業務をきちんと理解しないで作ったら、リリースしてもあんまり使われなかったり不評なものができるきちんと整理されてないプログラムを書いたら、あとから修正するのがどんどん大変になる DDDは、このの2個とも解決しよう、ということで生まれた設計・開発手法な

peketamin 2020/03/30

DDD

リンク

DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか - little hands' lab

Object-Oriented Conference 2020で登壇させていただきました。その際の発表資料です。発表資料 DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか from Koichiro Matsuoka www.slideshare.net 本章の内容は技術書典8(2020/3/1)で頒布予定の「ドメイン駆動設計モデリング/実装ガイド」の1,2章の内容になります。全部で11章仕立てです、興味お持ちいただけたらお買い求めください。受け取りは技術書典以降になりますが、それでもよろしければboothで予約可能です。 little-hands.booth.pm また、実践にあたって頻出の疑問に対してトピックごとに詳しく解説した書籍もあります。重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具

peketamin 2020/02/17

改善before/afterを交えた丁寧な解説

DDD

リンク

議論が噛み合わないと思ったら、「問題解決の5階層」でどこがずれているのか確認する - little hands' lab

チームで議論するときに常に心がけているのが、「問題解決の5階層」です。この図で重要なことは、下の階層で認識が一致していないと、上の階層では絶対認識があわないということです。「あれ、議論が噛み合っていないな？」と思ったら、この階層に照らし合わせて認識があっていないことがないか確認しましょう。問題認識のすれ違い例えばこのように問題の認識の違いがあったとします。なぜ違いが生まれたのでしょうか？コードの保守性に関する経験や、スキルの違い？と考えてしまうかもしれません。でも実際は、こうでしたこの話題に出てきたときの、認識していたコードが違うものだったのです。このような場合、事象の認識を合わせて初めて、問題の認識を合わせることができます。このようなケースは非常に多いです。普段一緒の空間で仕事をしていても、個人作業をしている時間は多いほど、人によって見えているもの、体験したこと

peketamin 2019/12/16

リンク

CQRS実践入門 [ドメイン駆動設計] - little hands' lab

この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題解決策 CQRSのメリット、デメリット実装時の注意事項部分的導入についてなぜQueryServiceの定義がUseCase層なのか整合性をどうやって担保するのかよくある誤解データソースを分ける必要があるのかイベントソーシングとの関係過去資料との繋がりもっと詳しく知りたい方は現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。参考過去記事

peketamin 2019/12/04

リンク

DDD基礎解説：エンティティ、値オブジェクトってなんなんだ - little hands' lab

はじめに DDDの実装パターンとして、エンティティと値オブジェクトというものがあります。ドメイン駆動一般に複雑な抽象論が多い中で、コードに近く一番イメージがつきやすいコード事例として出てくるため、ここだけは何となくわかるぞ！という方もいらっしゃるのではないでしょうか。今日はこちらの概要とそれぞれの使い道について書きたいと思います。先にざっくりイメージ図をお伝えすると、こういう図を使って解説します。何の目的で作るのか？ドメイン駆動設計は何を解決しようとしているのかこちらの記事で、ドメイン駆動設計のアプローチは以下の2ステップがあるということを書きました。ドメインの問題を解決するための抽象的なモデルを作る. モデルをソフトウェア(コード)に落とし込む ※ ドメイン＝ソフトウェアを適用して問題解決しようとする領域 DDDでは、このStep2のモデルをコードで表現するためのパターン

peketamin 2019/08/05

リンク

ドメイン知識とユースケースの違いは何か？[ドメイン駆動設計][DDD] - little hands' lab

DDDの文脈の中で、「ドメイン知識とユースケース(≒アプリケーションの知識)は何が違うのか？」という疑問がよく持たれます。この記事ではその違いを説明し、DDDのコードにどう反映するかを書きます。あるToDoアプリの仕様事例として、ToDoアプリの話をします。「仕様を決める」と言ったとき、以下のように箇条書きで決めることがあると思います。(Jiraのようなチケット管理システムのチケット詳細として書いたりしますよね) ユーザー登録、非活性化ができるメールアドレスは重複登録できないタスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができるタスクは3回までしか延期ができない非活性化されていないユーザーにアサインができるタスクを完了、アサインするとタスクレポートが作成されるこれはいわゆる「ビジネスロジック」と呼ばれて、3層レイヤーのアーキテクチャではBusine

peketamin 2019/07/27

リンク

ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab

DDD連載記事背景・前提なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。と書きました。こちらに対して、私が「一番とっつきやすい」と考えるアーキテクチャを紹介します。前提としてですが、完全に個人的な経験に基づく私見になります。 DDDの理論の中で、アーキテクチャに関しては「エリック・エヴァンスのドメイン駆動開発」(以下原典)と実践ドメイン駆動開発(以下IDDD)とでも異なったものが紹介されており、唯一の正解

peketamin 2018/08/24

リンク

コードレビューにこそ、コーチングのアプローチを適用するべきかも - little hands' lab

3つのコミュニケーションパターン会社でコーチング研修があり、(主に部下と1on1を想定して)コミュニケーションパターンが以下の3つに分けられるという話がありました。コーチング：「答え」は相手の中にある相手の話を聞く/問いかける/人となりを認めるティーチング：「答え」はこちらにある知識ややり方を教える/相手が理解してないことを説明するフィードバック：成長を促すために、周りからどう見えているか、思われているかを伝えるポイントは「いつもティーチングで自分が思うことばかり言ってしまってないか？アプローチには種類があることを認識し、適切に使い分けていこう」という話でした。これだけでもとても面白い話だったのですが、「これ、コードレビューでも同じではないか？」と思ったのです。レビューにおけるティーチングとコーチングティーチングティーチングはいわゆる「指摘」です。プルリク

peketamin 2018/01/15

リンク

モデルでドメイン知識を表現するとは何か[DDD] - little hands' lab

DDD連載記事なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかドメイン駆動設計の定義についてEric Evansはなんと言っているのかモデルでドメイン知識を表現するとは何かドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かドメイン駆動 + オニオンアーキテクチャ概略概要 DDDの定義についてEric Evansはなんと言っているのかこの記事でドメイン駆動開発の定義は以下のようなものであると書きました。ドメインの中核となる複雑さと機会に焦点を当てるドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する明示的にそれらのモデルを表現するソフトウェアを書く境界付けられたコンテキストの中のユビキタス言語で話すでは、ドメインの知識を言語化したモデルは、最終的にコードでどのように表現されるのでしょうか？不変条件まず、業務の制約に

peketamin 2017/12/21

リンク

境界づけられたコンテキスト実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab

little-hands.hatena blog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。境界づけられたコンテキスト実装の基本イメージ結論からいくと、基本的には、 1コンテキスト = 1アプリケーションと思ってもらってOKです。これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、以下のようにアプリケーションを2セット作ります。ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、

peketamin 2017/12/07

リンク

ドメイン駆動設計の定義についてEric Evansはなんと言っているのか[DDD] - little hands' lab

DDD連載記事なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかドメイン駆動設計の定義についてEric Evansはなんと言っているのかモデルでドメイン知識を表現するとは何かドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かドメイン駆動 + オニオンアーキテクチャ概略背景ドメイン駆動設計について、「どうやって実装するのさ？」の前に、まずは定義について認識合わせをしたいと思います。「ドメイン駆動設計とは何か？」ドメイン駆動設計について興味を持った時に、一番最初に疑問に思うのがこれですね。ところが、ググって見ると結構いろんなサイトでいろいろな書きぶりをしているんですよね・・・。「顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法」ドメイン駆動設計のメリットと始め方(Codezine記事) - 「厳しい現実の中

peketamin 2017/12/04

リンク

境界づけられたコンテキスト概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab

境界づけられたコンテキストとは公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界づけられたコンテキスト特定のモデルを定義・適用する境界を明示的に示したもの。代表的な境界の例は、サブシステムやチームなど。まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。境界づけられたコンテキストは、2つの観点から解説が必要でしょう。・概念としての境界づけられたコンテキスト・境界づけられたコンテキストをどう実装に

peketamin 2017/11/28

リンク

はてなブックマーク

タグ

ブックマーク / little-hands.hatenablog.com (19)

お知らせ

今週のはてなブックマーク数ランキング（2024年5月第3週）

今週のはてなブックマーク数ランキング（2024年5月第2週）

今週のはてなブックマーク数ランキング（2024年5月第1週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス