[B! DDD] t28atenaのブックマーク

t28atena id:t28atena

DDDに関するt28atenaのブックマーク (6)

Microservices分割大全 - kawasima
Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。したがって、コンウェイの法則にしたがった分割とされる。サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ
t28atena 2020/08/27
DDD

Architecture
リンク
ドメイン駆動設計を理解する３つのキーワード - ソフトウェア設計を考える
ドメイン駆動設計との出会い１０年前に、エヴァンスのドメイン駆動設計を初めて読んだ時は、書いてある内容がほとんど理解できなかった。あまり、面白いとも思わなかった。当時は、現場でバグだらけのコードと格闘していた。障害が報告されるたびに、リファクタリング本を参考に、該当個所の長いメソッドや大きなクラスを片端からリファクタリング。その結果、コードがわかりやすくなり、やっかいなバグが単純な修正で解消できてしまうことの効果に驚き、設計の重要性を再認識していた。それ以前は、UNIXとC言語、OracleとPL/SQLという、オブジェクト指向ではない世界で技術を身に着けてきた。どちらかというとオブジェクト指向には、ネガティブな印象を持っていた。現場では役に立たんだろうと。バグとの格闘の中で、リファクタリング（設計改善）の威力を肌で感じ、その考え方とやり方がオブジェクト指向に由来するということを
t28atena 2019/03/05
DDD

Programming

Development
リンク
DDDとコードとしての正しさ - pospomeのプログラミング日記
ドメイン駆動設計 #1 Advent Calendar 2018の14日目を担当する@pospomeです。今回はDDDとコードとしての正しさについて書いてみようと思います。 DDDは設計手法であるコードとしての正しさコードとしての正しさを見失うユースケースの日本語を"そのまま"コードに落とし込もうとする無駄にオブジェクト同士の結合度を上げる RubyのActiveRecordの正しさコードとしてのメリット、デメリットを具体的に考えて解決するまとめ DDDは設計手法である DDD = ドメイン駆動設計ですよね。 "設計"という単語が付いていることから分かる通り、DDDはあくまでソフトウェアにおける設計手法です。そのためDDDの成果物は"コード"であり、DDDの目的は"コードの可読性を上げること"であると自分は考えています。 DDDが持つ"ビジネスを理解する", "ドメインを
t28atena 2018/12/14
DDD

Programming
リンク
ドメインオブジェクトの責務について - Qiita
設計するとき、「このオブジェクトの責務は何だろうか？」とか「この責務に名前をつけるなら何か？」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。責務とは困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven design)」の原則に従うことが大きいとされています。この書籍によると、「責務」には以下が含まれるそうです。「4.1 責務とは何か」オブジェクトが行う動作オブジェクトが持つ知識オブジェクトが他に影響を与える主要な判断これらの言葉を身近な言葉で置き換える
t28atena 2018/11/18
DDD

Architecture
リンク
ドメインモデリングの始め方 - Speaker Deck
ドメイン駆動設計の考え方は書籍を読むとわかりますが、いざモデリングを実践しようとすると、どこから手を付けていいかわからない、ドメインモデリングの始め方がよくわからないという意見を聞きます。このスライド資料では、そんな悩みを持つ皆さんに向けて「ドメインモデルを見つけ出し・実装に落とし・改善していく」方法を、できるだけわかりやすく解説します。
t28atena 2018/11/18
あとで読む

DDD

Slide

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

Architecture

あとで読む
リンク
1