タグ

関連タグで絞り込む (23)

タグの絞り込みを解除

dddに関するigrepのブックマーク (24)

  • 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

  • Repositoryパターンのアンチパターン - Qiita

    よく見かけるRepositoryパターンのアンチパターンの紹介と対策です。 Repositoryパターンとは Repositoryパターンとは永続化を隠蔽するためのデザインパターンで、DAO(DataAccessObject)パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。 例えばDBコネクションやストレージのパス等はReposiotoryのインターフェースからは隠蔽され、Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになります。 これによりRepositoryを利用するロジックは業務的な操作に集中できるようになる他、データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離すことができるようになります。 // 例) ユーザ

    Repositoryパターンのアンチパターン - Qiita

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


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

  • 関心の分離を意識した名前設計で巨大クラスを爆殺する - Qiita


    大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名﹁神クラス﹂とも﹁大きな泥団子﹂とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの﹁商品﹂を考えてみます。 よくありがちなのは、商品をそのまま﹁商品クラス﹂と設計してしまうこと。 単純な商品クラスは、往々にして出品、予約、注文、発送など、様々なユースケースのクラスと結合してしまいがちです。 商品クラス自体も、結合したクラスに関連する知識(ロジック)を持ち始め、どんどん巨大化複雑化していきます。
    関心の分離を意識した名前設計で巨大クラスを爆殺する - Qiita
    igrep
    igrep 2019/10/31
    "利用規約には、製品の取り扱いやルールに関して極めて厳密な言い回しで書かれており、特化した名前の参考になります。" なるほど。うまく設計すれば逆の現象も起こせるかも
    リンク

  • 10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由｜ハイクラス転職・求人情報サイト AMBI（アンビ）

    10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由 10年以上運用されているサービスには、さまざまな技術的な負債が発生しています。今後の継続的な改善のため、いったん新規開発を止めて4年かけて全面的なリニューアルを実施した「はてなブックマーク」の開発者に、プロジェクトの課題や解決する手法などを聞きました。 改善1つに数カ月かかるなら全てを書き換えられないか 2000年代にトレンドだった開発手法の負債 過去の開発意図を探る考古学的手法 データセンター移行も見据えて刷新しよう ドメインモデル設計とScalaとマイクロサービス化 コアロジックにはScalaを採用 きちんとしたドメインモデルによる設計と実装を継続したい 段階的なリリースとデータの移行という2つの大きな課題 求められる機能に沿ったデータベーススキーマに再構築 新旧の2システムを維持しながら

    10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由｜ハイクラス転職・求人情報サイト AMBI（アンビ）
    igrep
    igrep 2019/09/05
    "「どんな機能にしましょうか」「どういう名前にしましょうか」といったことを、例えばサポートの人も巻き込んで、一緒に議論していきました" これぞDDDって感じだ。超すごい。
    リンク

  • ドメインロジックはドメインオブジェクトに凝集させる - Qiita


    こんにちは。 最近、こんなツイートしたのですが、ドメインオブジェクトではなくアプリケーションサービス1などにドメインロジックが書かれてしまうことがあります。 アプリケーションサービスはドメインロジックを配置する場所ではない、それはドメインオブジェクトの役割。アプリケーションサービスは進行役。ここを間違うから簡単にドメインモデル貧血症になってしまうんだと思います。 — かとじゅん (@j5ik2o) August 18, 2019 最近、以下の書籍(以下 増田本)をマジメに読み直しました(笑)。ドメインモデル貧血症2を回避して、ドメインロジックをドメインオブジェクトに凝集させる方法に関して、増田本にいろいろ書いてあったので、そのエッセンスと僕の考察を交えて解説したいと思います3。 詳しい内容は以下の増田本を読んでください！ コード例はScalaですが難しい表現がないので、Scalaが分からな
    ドメインロジックはドメインオブジェクトに凝集させる - Qiita
    igrep
    igrep 2019/08/28
    この手の話聞く度に、あるモジュールがどんな関数を他が使えるようにすべきかって、そのモジュール自身では決められず、モジュールの組み合わせに依存することが多いと感じる
    リンク

  • 忙しいひとのためのCQRS/quickly-cqrs - Speaker Deck

    All slide content and descriptions are owned by their creators.

    忙しいひとのためのCQRS/quickly-cqrs - Speaker Deck
    igrep
    igrep 2019/05/19
    簡潔で分かりやすい
    リンク

  • go言語でクリーンアーキテクチャっぽいもの | IIJ Engineers Blog


    IIJ プロダクト本部 応用開発課 所属。2015年に新卒入社。webアプリケーションの実装・運用を中心にやりたいことがあれば何でも手を出してみる所存です。 ︻IIJ 2018 TECHアドベントカレンダー 12/6︵木︶の記事です︼ はじめに 最近go言語でDDDやクリーンアーキテクチャを実践してみたという記事を多く目にするようになりました。 自分が半年ほど前に初めてgoでサーバーを実装することになった際も、先人達の記事のおかげでどうにか形にすることができました。 特に pospome さんの Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える はとても参考にさせていただきました。 ︵勝手に出してしまって申し訳ありません。︶ 恩返しというわけでは無いですが、自分なりに消化して実装したものを紹介したいと思います。サンプルコードは実際のコードを元にでっち上げて書いているので
    go言語でクリーンアーキテクチャっぽいもの | IIJ Engineers Blog

  • ドメインオブジェクトを中心としたClean Architecture のためのレイヤー構成 - Qiita


    ドメインオブジェクトを中心としたClean Architectureは、どういうレイヤー構成にするとよいか、簡単にまとめてみた。 イメージ たぶん、こんな感じになるはず。通常は円状に表現するが、わかりにくいので層状に書いてみた。 赤い部分の層は、直接依存の方向が上から下です。グレー部分の層は、契約だけが定義された独立した層で、ユースケース層やインターフェイス層から依存できるものとします。 インターフェイス︵アダプタ︶層 内外とのデータ形式の変換が主な役割 コントローラ、プレゼンター︵内部から外部へデータ形式を変換する責務︶,ゲートウェイ(外部と通信する責務。DBやRPC) ユースケース層 アプリーケーション層ともいう アプリケーション固有のビジネスルールをカプセル化する ドメイン層 Clean Architecture本では、中心にはエンティティとだけ書かれているが、DDDでは中心はドメイ
    ドメインオブジェクトを中心としたClean Architecture のためのレイヤー構成 - Qiita

  • The DDD Do-Over

    igrep
    igrep 2018/10/29
    リンク

  • Azure Functions で Domain-Driven Design (DDD) の Domain Event を実装する - atsukanrockのブログ


    この記事は Sansan Advent Calendar 2017 の25日目、すなわち最終日の記事です *1。ネタもないので参加する気はなかったのですが、とある社内バー的なもので酔っ払っていたところ会社の新卒君である id:kanjirz50 が目を輝かせて﹁最終日を飾ってください！！﹂と言ってきたのであまりのピュアネスが眩しくて二つ返事で快諾してしまいました。というわけでネタに困っています。 なんでそんなにネタに困っているかというと、実はここ2年弱程、開発者ではなくて開発マネージャーをやっていた関係で、技術ネタがないのです。この11月から改めて開発者になったので、今はリハビリ中でして、技術ネタは徐々に溜まってくると思います。 Advent Calendar と言っても必ずしも技術ネタである必要はなくて、 Sansan Advent Calendar 2017 では5日目
    Azure Functions で Domain-Driven Design (DDD) の Domain Event を実装する - atsukanrockのブログ

  • DDDをHaskellで考える 業務ロジックとシステムロジック - Qiita


    DDD初心者が拙いHaskellを使って色々考える試みです。 はじめに DDDは会社で見よう見まねで1年実践したけど、DDDの勉強はほぼ一切していないくらい。 Haskellは入門書をなんとか通読できたくらい、けど普段書いてないので全然馴染んでないくらい。 それくらいの奴が1年経ってやっと﹁ちょっとまじめに考えてみるかぁ﹂って思って考えたことをまとめる記事です。 記事の主軸はDDDなので、Haskellは読めなくても雰囲気だけ察してもらえると良いな、と思います。 また、Haskellを選んだ理由はこの記事を通して伝えたいと思います。 Haskellについて この記事を読むに当たり最低限必要なHaskellの文法を記載します。 僕がDDDを捉えるに当たり用いた考え方が一番含まれる点なので、まとめてみたいと思います。 参照透過性と副作用 Haskellには﹁参照透過性が常に保たれる処理﹂と﹁副
    DDDをHaskellで考える 業務ロジックとシステムロジック - Qiita
    igrep
    igrep 2017/12/20
    SQLとIOが絡みそうなものに業務ロジックが混ざってしまうことがあるから悩ましいよね。そんな時こそSQLの組み立てに集中するrelational-recordなんでしょうけど。
    リンク

  • Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita

    本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション

    Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
    igrep
    igrep 2017/12/20
    網羅的で素晴らしい！
    リンク

  • お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiita

    お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考えるmodelDDD設計 みなさんは、Modelと言われたときに何をイメージしますか？ こんなアレを思い浮かべた方も多いかと思います。 マサカらせてください。やはりお前らのModelは間違っている。 アレをModelと呼ぶと何が不味いのか すみません、早速言い過ぎました。半分は正しいです。MVCの発明者、Trygve Reenskaug氏による1979年の説明によると、 Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects. 1 このように「Modelは単体のオブジェクトであっても

    お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiita
    igrep
    igrep 2017/12/14
    まあ、結局現場ごとに入り乱れちゃうんだろうけど、覚えておきたい
    リンク

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

    DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっ

    [DDD]ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か - Qiita
    igrep
    igrep 2017/10/09
    "依存関係逆転の原則によってDomain層がInfrastructure層に依存しなくなっていること"
    リンク

  • Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)


    ﹃るびま﹄は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について ﹃Rubyist Magazine﹄、略して﹃るびま﹄は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0062 号 バックナンバー Rubyist Magazine 0062 号Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist Magazine 0058 号 RubyKai
    Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
    igrep
    igrep 2017/09/09
    面白かった。Haskellでこういうのほしい
    リンク

  • GitHub - jdreaver/eventful: Event Sourcing library for Haskell

    igrep
    igrep 2017/05/17
    "Eventful: Haskell Event Sourcing + CQRS Library"
    リンク

  • GitHub - reactuate/reactuate: React/Redux stack (not a boilerplate kit)

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - reactuate/reactuate: React/Redux stack (not a boilerplate kit)
    igrep
    igrep 2016/02/08
    “Reactuate is an opinionated stack for building React/Redux-based frontend applications with a focus on DDD (Domain-Driven Design).”
    リンク

  • GitHub - gcanti/tcomb: Type checking and DDD for JavaScript

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - gcanti/tcomb: Type checking and DDD for JavaScript
    igrep
    igrep 2015/10/08
    “check the types of JavaScript values at runtime with a simple and concise syntax.”
    リンク

  • 某S社のddd(メイリオ)

    Java/Spring Boot/MyBatis/Thymeleafを使った、ドメイン駆動設計のサンプルコード。ビジネスルールに焦点を合わせ、計算モデルで複雑さを整理し、型指向のプログラミングで実装する、その具体例。

    某S社のddd(メイリオ)
  • 1 2 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.