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

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

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

Akineko 2024/03/18

ddd

リンク

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

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

Akineko 2022/06/01

ddd

リンク

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

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

Akineko 2022/01/28

ddd
設計

リンク

DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab

株式会社ログラスの松岡(@little_hand_s)です。ドメイン層のオブジェクトを設計する際に、重要な基本方針があります。ドメインモデルの知識を対応するオブジェクトに書く常に正しいインスタンスしか存在させないこの2つを守ると、非常に保守性の高いコードにすることができます。以下、詳細に解説します。ドメインモデルの知識を対応するオブジェクトに書くドメイン知識(ルール/制約)を表現する実装を、ドメイン層のオブジェクトに寄せていきます。この判断は、「ドメインモデル図に書かれた吹き出しの内容が、どの層で実装されているか」という基準に基づき行います。この基準はコード設計の指針として非常に役立ちます。設計の良し悪しというのはさまざまな基準があるため、レビューをしていてもいわゆる「俺の考えた最強の設計」同士が戦ってしまうことがあります。しかし、「ドメイン知識はドメイン層に書く」と

Akineko 2022/01/25

ddd

リンク

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

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

Akineko 2020/12/23

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 また、実践にあたって頻出の疑問に対してトピックごとに詳しく解説した書籍もあります。重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具

Akineko 2020/11/06

ddd

リンク

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

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

Akineko 2020/07/15

ddd
CQRS

リンク

新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab

ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かドメイン駆動 + オニオンアーキテクチャ概略以前こちらの記事でアプリケーションアーキテクチャについて書きました。こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。アプリケーションアーキテクチャ全体図とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。何かについて議論をする際は、「それはどの層の責務なの？」という

Akineko 2020/03/27

ddd

リンク

オニオンアーキテクチャにておいて、ドメイン層とアプリケーション層の責務はどう違うのか[DDD] - little hands' lab

ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か - 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.

Akineko 2019/07/10

リンク

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

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

Akineko 2018/12/18

ddd

リンク

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

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