タグ

DDDとあとで読むに関するkinokotvのブックマーク (19)

  • DDDやってみたら 実装以前の領域での学びが深かった話

    ふりかえりでふりかえることしかできなかったジュニアチームが、次の打ち手を出せるチームになるのにやったこと

    DDDやってみたら 実装以前の領域での学びが深かった話
  • ドメイン駆動設計の正体

    はじめに "ドメイン駆動設計は当たり前のことを言っているだけ" "ドメイン駆動設計はただのオブジェクト指向プログラミング" "ドメイン駆動設計はより良いアーキテクチャだ" "軽量DDDはアンチパターンだ" このようなドメイン駆動設計に関する言及を聞いたことがあるでしょうか? ドメイン駆動設計に言及する記事や書籍は多くありますが、それぞれ着目する側面が異なったり色々なコンテキストから言及されています。 おそらくそれが原因でドメイン駆動設計が何であるかをぼやけさせ、正体のわかりにくい概念になっているように思えます。 そこで今回は色々な観点から整理し、ドメイン駆動設計とは何であるのか、その正体を考えていきます。 ドメイン駆動設計の基的概念について ドメイン駆動設計はEric Evansが出版した「Domain-Driven Design」という書籍がルーツになっています。 ドメイン駆動設計を一

    ドメイン駆動設計の正体
  • 『現場で役立つシステム設計の原則』を読みました - 人間のあるべき姿の探索

    はじめに 現場で役立つシステム設計の原則を知りたいと思っていたのですが、丁度現場で役立つシステム設計の原則について言及されている書籍があったので読みました。 gihyo.jp ある程度知名度のある書籍で、QiitaやZenn等でまとめられている方がいらっしゃるのですが、自分のアウトプットとして、感想も交えてまとめていきます。 全体の話 この書籍の雰囲気や見通しを立ちやすくするために、参考書籍の一覧を抜粋して紹介します。 『エリック・エヴァンスのドメイン駆動設計ソフトウェアの核心にある複雑さに立ち向かう』『新装版リファクタリング既存のコードを安全に改善する』『SQLアンチパターン』『エンタープライズアプリケーションアーキテクチャパターン』『エクストリームプログラミング』 システム設計の全般を対象にしているのですが、ベースの思考としてはオブジェクト指向プログラミングから発展して、ドメイン駆動設

    『現場で役立つシステム設計の原則』を読みました - 人間のあるべき姿の探索
  • 『ドメイン駆動設計』の解説記事を書きました - ソフトウェア設計を考える

    日(1月18日)発売された、Software Design誌 2023年2月号の第一特集で「ドメイン駆動設計入門」を書きました。 執筆の意図と記事の概要を簡単にまとめておきます。 Software Design 2023年2月号|技術評論社 執筆の意図 特集のサブタイトルにある通り「設計力を磨きたい」読者が、ドメイン駆動設計の基礎を知ることで「設計の手法とアイデアの引き出し」を増やすことの役に立てればと思い執筆を引き受けました。 重視したこと 断片的な用語やパターンの解説でなく、ドメイン駆動設計の全体像と要点を伝える 全体像を伝えるための図や表を多めにした(ソースコードの例は少ない) 全体像と要点は、原典である『エリック・エヴァンスのドメイン駆動設計』(以下『ドメイン駆動設計』)の説明を中心にした ドメイン駆動設計の具体例として『ドメイン駆動設計』に出てくる国際海上貨物輸送の具体的な業務

    『ドメイン駆動設計』の解説記事を書きました - ソフトウェア設計を考える
  • DDD本を読むためには前提知識が非常に多いよ - Qiita

    初めに きっかけ 新人研修中にDDDとか、PoEAAとかの話が少しだけ出ました。 ただ、イマイチわからないとの声が多数。 理由 なぜなら予備知識がたくさん必要だからです。(ほんとに多い) これはわからなくて当然。 そこで 独断と偏見で、予備知識となる用語を解説します。 偏見多いので、より正確な情報は、書籍やWebで調べてね。 この辺を説明します UML クラス図/シーケンス図 デザインパータン GoF/PoEAA 階層化アーキテクチャ DDDのサマリ 知らなきゃいけない知識が多くて面倒だね。 説明しないけど、オブジェクト指向やデータベースとかの知識も必要だよ。 説明前にDDDのページを見てみよう!!! DDDの最初のページ 「エリック・エヴァンスのドメイン駆動設計」より ??? よくわからないね さっきの図って何? 灰色の中心部分はソフトウェア設計のモデリングを表しています。 モデリ

    DDD本を読むためには前提知識が非常に多いよ - Qiita
  • Value Objectについて整理しよう - Software Transactional Memo

    Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a

    Value Objectについて整理しよう - Software Transactional Memo
  • 最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita

    TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守(あるいは鹿鳴館精神)ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基線となりつつある、、、のか? まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ

    最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita
  • ドメイン駆動設計 モデリング/実装ガイド - little-hands - BOOTH

    書は、初めてDDDを学ぶ方、もしくは実際に着手して「難しい!!」と感じているエンジニアの方を対象とした、ドメイン駆動設計(以下、DDD)についての解説書です。 近年、ソフトウェアのレガシー化が社会的に問題になっていると言われています。 DDDはレガシー化への対策として非常に有用なものですが、日語で出ている書籍「エリック・エヴァンスのドメイン駆動設計」や「実践ドメイン駆動設計」は非常に重厚かつ難解で、初学者が実用に到達するまでには長い時間と試行錯誤が必要なのが実情です。 そこで書では、迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。 また、その後にはレイヤーごとの個別のトピックについて、1章ずつ詳しく解説します。 ■書の構成 書は以下の構成になっています。 「第1章 DD

    ドメイン駆動設計 モデリング/実装ガイド - little-hands - BOOTH
  • 設計/コードレビューで"常に"心がけるポイント - little hands' lab

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

    設計/コードレビューで"常に"心がけるポイント - little hands' lab
  • DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab

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

    DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab
  • ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]

    BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/

    ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
  • 実はDDDってしっくりこないんです - タオルケット体操

    DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット(といいつつほぼ忘れかけている)なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用(採用できているとは言っていない)しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい

    実はDDDってしっくりこないんです - タオルケット体操
  • ドメイン駆動開発を浸透させるための新しい取り組み - SO Technologies 開発者ブログ

    はじめまして、ライクル事業部 エンジニアの菊池@kichionです。 普段の業務では主にエンジニアチーム運営・運用の課題解決やビジネスサイドとのやり取りが多く、中長期目線でのアプローチを行っています。 エンジニアとして行っている技術選定や実装関連についてはZenn - kichionにも投稿していますので興味があればご覧になってください。 今回はライクル事業部として少しづつ取り入れ始めている「ドメイン駆動開発」に焦点を当てて見ます (ドメイン駆動に関わる内容については、端的ですがQiita - kichionにも投稿してますので気になったらご参照ください) ドメイン駆動開発(DDD) ドメイン ドメインモデリング 技術的要素 ドメイン駆動開発の目的 ドメイン駆動開発を浸透させるための取り組み ドメイン駆動開発 勉強会 ドメインオブジェクト整理会 今後やっていきたいこと 続・DDD勉強会 現

    ドメイン駆動開発を浸透させるための新しい取り組み - SO Technologies 開発者ブログ
  • 実践! Typescript で DDD - マイクロサービス設計のすすめ - Leverages Tech Blog

    対象読者 マイクロサービス化を検討しており、実際に作る場合の構成を参考にしたい。 ドメイン駆動設計について、基的な用語の知識がある。 TypeScript を多少触ったことがある。理解がある。 はじめに こんにちは。エンジニアの吉村です。 現在、弊社が運営する teratail というサービスに携わっており、CakePHP で動作しているモノリシックな既存サービスをマイクロサービスに移行するというプロジェクトを進行中です。 この記事では、実務を通して得た知見として、マイクロサービス化によりどんな恩恵があるのか、具体的にどのような構成で実装をしているのかについてご紹介します。 TL;DR マイクロサービスのバックエンドサービスの実装に焦点を絞って、ドメイン駆動設計 + オニオンアーキテクチャをベースに設計をしました。 記事では、具体的に「ユーザ新規登録処理」の実装をする場合を例にとり、実

    実践! Typescript で DDD - マイクロサービス設計のすすめ - Leverages Tech Blog
  • さよならアーキテクチャ議論|Seiji Takahashi@ベースマキナ

    ポエム。 つまり?予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん

    さよならアーキテクチャ議論|Seiji Takahashi@ベースマキナ
  • マイクロサービスにクリーンアーキテクチャを採用する上で考えたこと | メルカリエンジニアリング

    Merpay Advent Calendar 2019 の19日目は、Backendエンジニアチームの @toshinao がお送りします。 新しくマイクロサービスを立ち上げる機会があり、クリーンアーキテクチャをベースにしました。クリーンアーキテクチャはバックエンド・フロントエンド・アプリなど様々な場所で採用されています。ただ、確固たる方法というのは無く、みな試行錯誤しているのでは無いでしょうか。この記事では、クリーンアーキテクチャを取り入れる上で考えたことを紹介したいと思います。 マイクロサービスを作ったことがない人や、今までいくつか作ってきたけどより良い設計について考えている人の助けになれば幸いです。 はじめに メルペイのバックエンドは主にGoGoogle Cloud PlatformGCP)で開発を行っていますが、各マイクロサービスをどう実装していくかは概ね各チームに委ねられてい

    マイクロサービスにクリーンアーキテクチャを採用する上で考えたこと | メルカリエンジニアリング
  • Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository

    Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository

    Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository
  • 僕とDDDとClean ArchitectureとやっぱりDDD - kenfdev’s blog

    2022/04/21更新 ふりかえってみて、この記事は手段と目的をごっちゃにしちゃった自分がよくわかる記事です。 DDDは「どうやってコードを書くか」が問題ではありません。その点を勘違いしちゃってるエンジニアの話として、続きを読みたい人は読んでください🙏 DDD(Domain Driven Design)って難しいですよね。難しい難しいとばかり考えていた僕もようやく最近になって少しずつわかってきた気がします。そのきっかけとなった書籍と僕のストーリーを記事で紹介できたらと思います。 TL;DR Clean Architectureはなんとなくわかる DDDは難しい と感じている人は「Domain-Driven Design in PHP」を読むと道が拓けるかもしれない。 leanpub.com 僕とDDD DDDといえばEvansのドメイン駆動設計: エリック・エヴァンスのドメイン駆動設

    僕とDDDとClean ArchitectureとやっぱりDDD - kenfdev’s blog
  • ソースコードで理解するクリーンアーキテクチャ - Sansan Tech Blog

    はじめに こんにちは。プロダクト開発部の荒川です。 これまで最年少を謳っていましたが、ついに新卒の子にその座を奪われてしまいました。とても残念です。 さて今回のテーマは、皆さんお馴染みクリーンアーキテクチャ(Clean Architecture)です。 クリーンアーキテクチャは一時期流行し、その流れに乗って私もある程度の理解はしていました。 しかし、それはあくまでも感覚的な理解であって、他人に説明や良さを語れるレベルまで自分の中で落としこめていませんでした。 そこでより具体性のあるソースコードを読み込むことで、アーキテクチャへの理解を深めたいと思います。 クリーンアーキテクチャとは? クリーンアーキテクチャの定義や解説に関しては、ネット上にいくらでも公開されているので、このエントリでは詳しく話しません。 私自身が勉強に使った書籍やサイトを記事末尾の「参照」に掲載しているので、そちらを参考に

    ソースコードで理解するクリーンアーキテクチャ - Sansan Tech Blog
  • 1