このイベントの登壇資料です。 ミノ駆動さんが今伝えたいドメインモデリングの勘所 〜“想定外”を排するデータ破壊駆動設計とは？〜 https://findy.connpass.com/event/332976/
破壊せよ！データ破壊駆動で考えるドメインモデリング / data-destroy-driven
このイベントの登壇資料です。 ミノ駆動さんが今伝えたいドメインモデリングの勘所 〜“想定外”を排するデータ破壊駆動設計とは？〜 https://findy.connpass.com/event/332976/
削除のビジネスロジックをドメイン層に閉じ込める簡単で強力な「DeletableIDパターン」の紹介
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか？ 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか？は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか？」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
2022年10月1日に開催された #postdev での発表です
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/6a4c5f38eeedeba9c1ce48808acf9444e3af18a4/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F1d248988cd31ca6b1592926c741fcd58a4621157%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20191202%252F20191202061944.png)
アジャイル迷子のための「アジャイルの本質」。あとDDDとのつながり - little hands' lab
記事の構成 アジャイルソフトウェア開発とは アジャイルマニフェストとは アジャイルマニフェストの問題 そこで、アジャイルの本質 by マーティンファウラー アジャイルソフトウェア開発とは？ アジャイルソフトウェア開発とはなんでしょうか？ 「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」 これが最もオリジナルな定義です。 なぜこんなややこしい言い回しをするのは後から説明します。 重要なことは、「アジャイル」という具体的な手法があるわけではないということです。 アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。 アジャイルの思想に則った開発手法として ・スクラム ・エクストリームプログラミング(XP) ・リーンスタ
簡単にできるDDDのモデリング - ドメイン駆動設計 - little hands' lab
DDDではよく「モデリングが重要だ！」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。 そんな方のために、本記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。 (本記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。) DDDの目的 DDDの目的から確認しましょう。 DDDの目的は2つ。 ①機能性を高めること これは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。 そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。 ②保守性を高めること これは、長期間開発しても機能拡張が容易であり
書籍『良いコード/悪いコードで学ぶ設計入門』でエンジニアリングの当たり前を変える
こちらのトークイベントで用いたスライドです。 『良いコード/悪いコードで学ぶ設計入門』著者トーク https://modeling-how-to-learn.connpass.com/event/242976/
ドメイン駆動設計関連情報のググるときのコツ - little hands' lab
1.DDD関連でほしい情報は英語であるという覚悟を決める。 これは冗談のようですが本当です！笑 英語と日本語でDDD情報は本当に格差がある！！ DDDの記事、wikipediaですらわかりやすいんですよ。 こちらの記事もeric evansの公式サイト(当然英語)を調べていたら見つけたものです。 なので、DDDについて調べたけばまず英語で調べるという覚悟を決めましょう。 2.アメリカのgoogleにアクセスする 日本のgoogleで「domain driven design」と調べても日本語の資料がたくさん出てきてしまいます。それを回避するために、以下のURLからアメリカのgoogleを使用しましょう。 https://www.google.com/webhp?gl=us&hl=en&gws_rd=cr これはパラメーターに意味があります。 gl=us：国がUSであることを指定。 hl=e
DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 ドメイン層のオブジェクトを設計する際に、重要な基本方針があります。 ドメインモデルの知識を対応するオブジェクトに書く 常に正しいインスタンスしか存在させない この2つを守ると、非常に保守性の高いコードにすることができます。 以下、詳細に解説します。 ドメインモデルの知識を対応するオブジェクトに書く ドメイン知識(ルール/制約)を表現する実装を、ドメイン層のオブジェクトに寄せていきます。 この判断は、「ドメインモデル図に書かれた吹き出しの内容が、どの層で実装されているか」という基準に基づき行います。 この基準はコード設計の指針として非常に役立ちます。 設計の良し悪しというのはさまざまな基準があるため、レビューをしていてもいわゆる「俺の考えた最強の設計」同士が戦ってしまうことがあります。 しかし、「ドメイン知識はドメイン層に書く」と
![DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/8bbbcc5fc51e0aae863363c39f0a4d835f2e7aeb/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F9127e34aacb6d69e9d1976b3e74fcba3155008c4%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20220125%252F20220125074432.png)
質問はquerie.meからお願いします。の質問箱です
定義する人によって異なります。 大事なのは、そのクラスの責務(それは何を表す/何をするクラスなのか)を考えることです。引数オブジェクトは責務が明確ですね。特定のメソッドの引数を表すオブジェクトですね。名前もそのままで良さそうです。 では、データ転送オブジェクト(DataTransferObjectなので変換ではなく転送ですね)は何を表す、何をするオブジェクトでしょうか？おそらく、ここが曖昧ですね。転送とは何を表すのでしょう。これは、定義しないと定まらないのです。だからこそ、プロジェクトにおいてきちんと意味を定める必要があります。 例として、あくまで私が普段使用している定義では、オニオンアーキテクチャでユースケース層からプレゼンテーション層に値を受け渡すオブジェクトにDTOという名称をつけています。 https://gyazo.com/8232196108a851d6120f8fb09921
オブジェクト詰め替えが面倒臭い？マルチカーソルを使えば10秒でできます - little hands' lab
面倒臭いオブジェクト詰め替え オニオンアーキテクチャ、クリーンアーキテクチャなどの階層化されたアーキテクチャを使用する際、レイヤーの境界でオブジェクトの値を詰め替える必要性が発生します。 オブジェクトを詰め替えることでレイヤーの依存関係を断ち切り、一度書いた後の保守性を高めることに大きく貢献するのですが、筆者の観測範囲では単調作業に感じるせいかかなり嫌われる傾向があるように感じます。 そして、そのような詰替を嫌うばかりにオブジェクト詰め替えをやめてしまうこともありますが、それは非常にもったいないことです！！ なぜなら、「初期実装の数分の重要性 <<<< その後の保守性の重要性」だからです。 なので、できればきちんと詰め替えしてレイヤーの依存関係を保って欲しい、ということで、そのために詰め替えが超簡単にできる方法をご紹介します。 まずはデモご覧ください。 class Entity( val
DDDのエンティティはイミュータブルな実装にしてもいいの？(サンプルコード有り)[ドメイン駆動設計 / DDD] - little hands' lab
本記事はドメイン駆動設計（ＤＤＤ） Advent Calendar 2021の13日目の記事です。 エンティティとイミュータブル性 オブジェクトをイミュータブル、つまり内部状態を変えない実装にすることで可読性やマルチスレッド対応性が向上することがあります。 エンティティはモデリング上の定義はミュータブルなものですが、実装方法をイミュータブルにすることは可能です。 (DDDでは、エンティティはミュータブルもしくはイミュータブル、値オブジェクトは必ずイミュータブルという定義です。詳しくはこちら) DDD基礎解説：Entity、ValueObjectってなんなんだ - little hands' lab 本記事ではエンティティをイミュータブルな実装にするサンプルコードと合わせて、イミュータブルにした場合の旨みを感じられるコードを紹介します。 イミュータブルなエンティティ実装の例 エンティティをイ
![DDDのエンティティはイミュータブルな実装にしてもいいの？(サンプルコード有り)[ドメイン駆動設計 / DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/39cd1807233d4606c12a8c80e8c0a60b463148bf/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F3fe871ef96243ed70c00b2a079c09405763f0273%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20211213%252F20211213073035.png)
松岡@ログラス/DDD,アジャイルの質問箱です
2つのクラスが独立したものであれば選択肢としてはありです。2つ連続で呼ばないと整合性が壊れてしまう、など結合が強ければなしです。そのような場合はユースケースで一緒にやるべきです。 観点としては、コントローラーの処理が「クライアントからユースケースへの変換」という責務を超過しないかどうかです。2つのユースケースを続けて呼ばないと整合性が保てない、2つのユースケースを呼ぶ間に分岐が発生する、などの場合は変換の責務を超え、特定のユースケースを実現しようとしていると考えられるので、ユースケースクラスで行うべきでしょう。
松岡@ログラス/DDD,アジャイルの質問箱です
パラメーターが多いという「不吉な匂い(コードスメル)」対策として代表的なのは、パラメーターオブジェクトを導入することです。5つの値を「XxxUseCaseParam」と言ったクラスに詰めて渡すのはよくやります。 プレゼンテーション層でエンティティを組み立ててしまうと、ユースケースと責務がごっちゃになってしまうのであまりお勧めしません。プレゼンテーションは何か意味のあるものの組み立てはせず、クライアントからきた値をユースケースに渡すために変換するところまでを責務とするとよいでしょう。
Clean Architecture on Frontend （翻訳） - Qiita
こちらはDEV Communityに2021年9月2日に投稿され、現在反響を巻き起こしているフロントエンドにおけるクリーンアーキテクチャの実装についてのAlexさんの記事になります（原文はこちら)(twitterにて翻訳掲載許可取得済み）。 かなり大ボリュームな超大作記事となっておりますが、Reactなどを使ったフロントエンドプロジェクトのディレクトリー構成やファイルごとの責務の切り分けのベストプラクティスなどの決定版といえるものがまだまだ出てこない中で、個人的にまさに待ち侘びていたような内容の記事かと思い、是非日本のフロントエンドコミュニティでも知見が共有されればと思いました。 それでは以下、本文です。 *翻訳は大部分をDeepL翻訳によって行っていますが、適宜修正してあります。 少し前に、私はフロントエンドにおけるクリーンアーキテクチャについての講演を行いました。この記事では、その講演
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『良いコード／悪いコードで学ぶ設計入門』を一歩深める読み方 / deepen good code bad code
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
Your connected workspace for wiki, docs & projects | Notion
Your connected workspace for wiki, docs & projects | Notion
松岡@ログラス/DDD,アジャイルの質問箱です
