タグ

ドメインに関するchigurihaguriのブックマーク (10)

  • [DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita

    DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほ

    [DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita
  • ドメイン駆動設計は何を解決しようとしているのか[DDD] - Qiita

    ドメイン駆動設計の定義についてEric Evansはなんと言っているのか の記事の中で、EricEvansのドメイン駆動の定義を引用して以下のように和訳しました。 ドメインの中核となる複雑さと機会に焦点を当てる ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する 明示的にそれらのモデルを表現するソフトウェアを書く 境界付けられたコンテキストの中のユビキタス言語で話す この中で、重要なポイントが明示されていませんでした。 定義にある4点のようなことを、なぜやる必要があるのか? ということです。 つまり、ドメイン駆動設計は、一体何を解決しようとしているのでしょうか? ドメイン駆動設計は何を解決しようとしているのか DDDはソフトウェア開発手法の一つです。 なのでまず、ソフトウェア開発の目的について考えてみましょう。 人々はなぜ、ソフトウェアを開発するのでしょうか? それは、

    ドメイン駆動設計は何を解決しようとしているのか[DDD] - Qiita
  • ドメイン駆動設計 本格入門

    ドメイン駆動設計の考え方、ドメイン駆動設計を理解する三つのキーワード、エヴァンスのススメ、レガシーに立ち向かう、マイクロサービスとドメイン駆動設計Read less

    ドメイン駆動設計 本格入門
  • ドメイン駆動設計 #1のカレンダー | Advent Calendar 2018 - Qiita

    ドメイン駆動設計(DDD)に関するアドベントカレンダー。DDDに関することであればなんでもOK。 「エリックエヴァンスの」としてないので、ドメインを扱う設計手法であればOKです。実践ドメイン駆動設計でも、CQRS(Event Sourcing), クリーンアーキテクチャとかでもよいですが、必ずドメイン駆動設計にどう関係するか書いてくださいね。 あと、議論のきっかけにできればよいと思いますので、入門的なこと・高度なこと・成功したこと・失敗したこと・改善の余地などハードルは下げますので、自由に書いてください。 推奨ハッシュタグ #ドメイン駆動設計 ドメイン駆動設計 #2 Advent Calendar 2018 もあります! https://qiita.com/advent-calendar/2018/ddd-2

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

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

    ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab
  • [grails]Grailsベストプラクティス - uehaj's blog

    InfoQ記事の翻訳です(日語版で翻訳されない…orz)。 わたし(Amit Jain氏)はIntelliGrapeというGroovy&Grailsを専門とする会社で働いています。この記事は、私たちのGrailsプロジェクトが従う、メーリング・リスト、スタック・オーバーフロー、ブログ、ポッドキャストsおよび内部議論から集めたベスト・プラクティスの基礎的なリストです。コントローラー、サービス、ドメイン、ビュー、taglibs、テストおよび一般に分類しています。 コントローラー コントローラーが他の役割を兼ねてはいけません。コントローラーの役割は入力リクエストを受け入れ、パーミッションをチェックし、結果をドメインあるいはサービスに確認し、HTML、JSON、あるいはXMLなどの期待されるフォーマットでリクエスト側に結果を戻すことです。コントローラーはできるだけ薄くしてください。コントローラー

    [grails]Grailsベストプラクティス - uehaj's blog
  • 翻訳に必要な3つの技術 - Digital Romanticism

    翻訳に必要と思われる技術について整理する。 導入 私のブログの書き方を紹介したエントリの中でもすこし触れたとおり、翻訳という作業は自分の中で大きな位置を占めるようになってきています。『エリック・エヴァンスのドメイン駆動設計』が出版されて以来、新しい翻訳をやったり、他の方の翻訳をレビューに参加させて頂いたりと、翻訳がらみの仕事が増えてきましたので、この機会に自分が考えていることを整理したいと思います。 なお、この場を借りて大先輩の翻訳論をご紹介しておきます。 翻訳の心がけ - 結城浩さん http://capsctrl.que.jp/kdmsnr/diary/20110326p01.html - kdmsnrさん 私の考える、翻訳に必要な3つの技術とは「英文解釈」「翻訳のテクニック」「日語作成技術」です。結局のところ翻訳とは、「英文を正確に理解し」「日語に置き換え」「日語として自然に読

    翻訳に必要な3つの技術 - Digital Romanticism
  • ドメイン駆動設計・俯瞰編 - Strategic Choice

    書籍「エリック・エヴァンスのドメイン駆動設計」にある全パターンを、3枚の俯瞰図にまとめます。ボリューミーなこのを攻略するのに、この自身にある「大規模な構造(第16章)」という戦略に倣おうと考えたからです。巨大なシステムに包括的な原則がなく、そのせいで各要素を解釈する際に、設計全体にまたがるパターンにおいてどのような役割を果たすかという観点から考えることができなければ、開発者は「木を見て森を見ず」になってしまう。全体の詳細を徹底的に調べなくても、全体の中で個々の部分が果たす役割を理解できる必要があるのだ。「大規模な構造」は、システムをおおよその構造から議論し、理解できるようにするための言語である。第16章 大規模な構造 P447-448「パターン」の仔細を見る前に、各々の「コンテキスト」の中での「立ち位置」をわかっておいたほうが、理解が「速い」し「深まる」と思います。まず「全体における部

  • 長年、邦訳されなかった「思慮深いソフトウェア開発者全員の必携書」

    Domain-Driven Design」通称「DDD」の原著が出版されたのは、2003年のことだった。Kent Beck氏が賛辞に寄せた「思慮深いソフトウェア開発者全員の必携書」という言葉が示している通り、英語圏では圧倒的な支持を集め、出版から7年が経過した現在でも、Yahoo! Groupsのメーリングリストでは活発な議論が交わされている。 一方、日では少し状況が異なる。識者の間では、有用な書籍として早くから知られていたものの、500ページ超という厚さと、文体の難しさが、多くの日エンジニアの挑戦を阻んできた(邦訳も待ち望まれたが、長い間出版されなかった)。 佐藤匡剛氏による「Domain-Driven Designのエッセンス」、徳武聡氏による「DDD Quickly 日語版」をはじめ、日語の情報は少なからず存在したし、国内での実践事例も徐々に蓄積されていたものの、質的に

    長年、邦訳されなかった「思慮深いソフトウェア開発者全員の必携書」
  • DDD Sample Application - Architecture

  • 1