[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほ
![[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/5f74c5c72ebd18816032917216eeec82801e95ef/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCREREJTVEJUUzJTgzJTg5JUUzJTgzJUExJUUzJTgyJUE0JUUzJTgzJUIzJUU5JUE3JTg2JUU1JThCJTk1JTIwJTJCJTIwJUUzJTgyJUFBJUUzJTgzJThCJUUzJTgyJUFBJUUzJTgzJUIzJUUzJTgyJUEyJUUzJTgzJUJDJUUzJTgyJUFEJUUzJTgzJTg2JUUzJTgyJUFGJUUzJTgzJTgxJUUzJTgzJUEzJUU2JUE2JTgyJUU3JTk1JUE1JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz05MGViZDg5M2ZkOGVlMDZkMGEyOWVkZWMyN2MxMmFkNg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBsaXR0bGVfaGFuZF9zJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02YmZmYzI2ZTBkMjNhZjllYjRjZTJiYTQwODIzMjhhNA%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Da55a404321a639c6fc4f1c3992cbb2b3)
Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから
責務と層の分離
設計の話 設計の話です。 責務 責務、誰がその仕事を行うかということを考えましょうというのはまぁさんざん言われていることだけど実際大事だと思う。 テクニックとしては委譲だのなんだのとあるけど、結局は「その仕事はその人に任せて本当にいいの？」にYesと答えられる場合にのみその作業をそのモジュールなり関数なりクラスなりに任せましょうという話ですね。 層の分離 プログラムが行う仕事は通常いくつかのオペレーションを組み合わせて実現されるわけだけど、それらの重要度というのは普通は一様ではない。 仕事によってはドメインレベルにしっかり固定されそれ以外のオペレーションがあり得ないものもあるし、今は一旦こうして実装しておくがあとで高確率で置き換える必要があるとかそういうやつ。 例えば今はハードコードしているが設定ファイルから読み込んだ値にしたい、DBを切り替えたい、データの中身が変更したいとかそういう感じ
ドメインモデルをコードへ落とす 〜あなたのクラスは、どこから？〜 - Qiita
annotation: 現在コメントいただいている通り、一部誤りを含んでいる様です。 追って確認・修正いたしますが、現行ではコメントも合わせてお読み頂ければと思います。 こんにちは、風邪はだいたい喉から来るぷーたんです。 「DDDの構成要素はこれだー」というのはたくさんあったのですが、 「このドメインオブジェクトはどの要素だー」と逆引きするものがなかったので調べてフローチャートにしてみました。 例えばドメインモデル図とコードがうまく合致しない時の見直しなどに使えるのではと考えています。 ではご覧ください♪ 検討フローチャート 図1.フローチャート 1) 複数のドメインオブジェクトを扱い、整合性を担保するか まず複数のドメインオブジェクトを扱うかを考えます。 ドメインモデル図では集約線が引かれていたり、複数の関係線が引かれていたりします。 図2.ドメインモデル図の例 上記のような場合であれば
最近のアプリ界隈での「設計」の違和感 - なるようになるかも
アプリ界隈で「設計」の話をするときに MVC / MVP / MVVM のような「設計パターン」だけが語られるようになった気がする。 往々にして、「アプリの規模によってどれを採択すべきかは変わる」みたいなお茶を濁すような結論で終わることが多い。 私的な結論 「設計」と、「設計パターン」は別物だと思う。 「設計」のレベルを上げたい。 アーキテクチャシンドロームから抜け出して、価値のあるものを作りたい。 以下、思うところのメモ。 MVC は古い / 劣ったやり方か？ MVC は Model をどう構築するかについてとくに規定していない。 MVC への批判をするときに、FatVC が持ち出されることが多いのですが、FatVC を実装してしまうのは単に実装者の能力不足だと考えていて、MVVM を採用しても FatVM を作るだけだと思っている。 また、比較的新しめの Flux アーキテクチャは、良
ドメイン駆動設計と関数プログラミングをScalaで - Qiita
はじめに この記事は Scala Advent Calendar 2016 - Qiita の 7 日目の記事です。 私事で恐縮ですが、今年の個人的なハイライトは、遅まきながらドメイン駆動設計と関数プログラミングを学べたことでして、その中でも、"Functional and Reactive Domain Modeling" (Debasish Ghosh 著) (以下、FRDM本) を読んで、ふたつのコンセプトが自分の中で繋がったことが最も大きなものでした。 Manning | Functional and Reactive Domain Modeling この記事では、本書の紹介も兼ねて、ドメイン駆動設計がどのように関数プログラミングと結びつくのか、非常にざっくりではありますが、Scala で表現してみたいと思います (ちなみに、私の Scala 歴は3ヶ月ほどですので、サンプルコード
日本語のドメイン駆動設計 (Domain-Driven Design - DDD) 関連記事まとめ - なにか作る
ドメイン駆動設計は原典となる「エリック・エヴァンスのドメイン駆動設計」の初版が2003年と歴史があり、モダンなフレームワークであればその思想を取り入れた設計がなされているにも関わらず、日本語の情報が少ない気がする。 最近ドメイン駆動設計をやろうと主にWeb上の情報を探っていたので参考になったサイトをリンク集の形でまとめてみる。 概要 概要を把握するのが一番難しいように思うので、色々と目を通すのがよさそう。 little-hands.hatenablog.com enterprisegeeks.hatenablog.com enterprisegeeks.hatenablog.com speakerdeck.com ドメイン駆動設計とは何か 【入門編】 from 増田 亨 www.slideshare.net 3週連続DDDその1 ドメイン駆動設計の基本を理解する from 増田 亨 www
Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する Androidアプリの開発において悩ましいアーキテクチャの選定。本記事では選定する意味を改めて整理し、 MVP・Clean Architecture・MVVM・Fluxといった最新の実例を紹介します。 はじめまして。Androidエンジニアの藤原聖（ふじわら・さとる／@satorufujiwara）です。 現在は株式会社サイバーエージェントで、エンジニアリングマネージャーを兼任しています。2017年で35歳になり、定年を迎えました（プログラマの定年については「体型を支える技術」などを参照）。 Androidアプリ開発には2010年から携わっていますが、今現在の関心事は何といっても公式開発言語に採用されたKotlin。そしてもう一つが、Androidの
境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
little-hands.hatenablog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、 以下のようにアプリケーションを2セット作ります。 ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。 最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、
![境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/651dc2c9022ca618fd318e11235cd199205385a3/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171207%2F20171207001225.png)
Goのパッケージ構成の失敗遍歴と現状確認
この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう
はじめてドメイン駆動設計をしてみて感じたこと - Qiita
この記事はCrowdWorks Advent Calendar 2017の4日目の記事です。 はじめに 今年CrowdWorksにエンジニアとして新卒入社した@kinakoboです。CrowdWorksでは10月から新たな試みとしてドメイン駆動設計（DDD）を実践しています。 DDDを実践するに至った経緯は、サービスの規模拡大に伴いアプリが肥大化し、技術的負債が増えてきたことで、機能追加をスピーディーに進めづらくなってきたからです。 今回実装しようとしている機能を今まで通りRuby on Railsを利用して実装することは可能ですが、変更に強い柔軟なサービスにするためにもDDD+Scalaで実装し始めています。 DDD未経験の状態から2ヶ月実践してみて、まだ道半ばですが感じたことを書きます。同じような課題感を持っている方の参考になれば幸いです。 エヴァンス本に挫折したら･･･ DDDと言え
境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
境界づけられたコンテキストとは 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界づけられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界づけられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界づけられたコンテキスト ・境界づけられたコンテキストをどう実装に
![境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/6bb65ba88fd34a29140629a2f7085b6e005c2663/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171128%2F20171128072027.png)
Railsの太ったモデルをダイエットさせる方法について - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はよくリファクタリングをしています。 今回は、最近僕がリファクタリングしている内容についてまとめようと思います。 メドピアではFat Model/Controllerを避けるために、rubocopの設定を利用しクラスの行数が300行以下になるよう制限しています*1。最近300行を超えるモデルが出てきたので、一部の処理を別のクラスに切り出し始めました。 このとき、Railsが提供している機能であるconcernsを利用すると楽に行数を減らすことができますが、それだとrubocopの指摘を回避できるという意味しかないので、なるべく委譲(composition)を利用して処理を別クラスに移していっています*2。 複数モデルにまたがる処理を切り出す Railsアプリケーションを書いていると、複数のモデルを一度
『現場で役立つシステム設計の原則』 増田亨さん を読んだ。「データしか持たないデータクラスは作らない！」 - エンジニア的なネタを毎週書くブログ
こちらの本を読んででのレポートです。現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法【電子書籍】[ 増田亨 ] 価格：3175円 (2017/11/4時点) 複雑な業務ロジックは「適切な境界」で分離されていれば理解しやすくなる！ …が最近の自分の持論なのですが、じゃあ「適切な境界」って何よ？ …と言われると、うまく言語化説明できない。 そんな私にたくさんヒントを与えてくれた本でした。 なかなか消化しきれていないところもあるのですが、腹落ちさせるためにもブログに落としてみます。 このブログに書いたことをまとめると・・・ 修正が大変なのはロジックが分散しているから データとロジックをひとつのクラスにまとめるとロジックが分散しない！ じゃあWeb APIでサービス間連携するときも、データを持つほうにロジックを寄せるべき… と思ったら、そうでもない？ この本のすごい
第3回 -ドメイン駆動設計のための オブジェクト指向プログラミング ハンズオン"に参加してきた！ - desi-gneer(designer_engineer)
今回はasoviewさんが主催された "ドメイン駆動設計のための オブジェクト指向プログラミング ハンズオン"勉強会に参加してきました。 asoview!（アソビュー）｜日本最大の遊びのマーケットプレイス まえがき 最近になって、また日に日にDDDの話題を見る機会が多くなってきていますね。そんな中、今回はasoviewさんが主催された勉強会に参加してきました。 本勉強会は1回2時間の勉強会を計3回実施するという、なかなか骨太な勉強会です。 (諸事情により、2回目は参加することが出来ませんでしたが…) これくらい時間をかけて行う勉強会はそう多くありませんが、 DDDを扱うにはこれくらい時間をかけて勉強会をするべきだとも思いました。 短い勉強会・発表だと、DDDの中で自分が気になっている箇所が取り扱われないこともよくありますし。 また、社内向けの勉強会を今回このように一般公開するという取り組み
なぜDDD初心者はググり出してすぐに心がくじけてしまうのか - Qiita
DDD連載記事 * なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか * ドメイン駆動設計の定義についてEric Evansはなんと言っているのか * モデルでドメイン知識を表現するとは何か * ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か * ドメイン駆動 + オニオンアーキテクチャ概略 背景 直近のプロジェクトでDDDの思想に則ったアーキテクチャで一つリリースまで漕ぎ付けまして、そこに至るまで色々と調べたり試行錯誤をしながら学んだことを書いていこうと思います。 一番にですね、大体のDDDに興味を持った人がいうのが ということなんですよね。 DDDは思想としてすごく面白く、とても実用性なものなのに、なんでこんなにわかりづらいのか、ハードルが高いのか！！ という点について、私なりの解釈を述べたいと思います。 心をくじく要因 Eric Evans本は説明
「現場で役立つシステム設計の原則」を読んでみたよ - runaround’s diary
平日は仕事前の30分、仕事後は時々晩御飯待ちの間に読書するようにしています。 今日まで読んでいたのはこちら。 books.rakuten.co.jp 厚さは結構あるのにとっても軽く、最近の製紙や製本技術の向上には驚かされます。 そして本を開いてみるとびっくり。案外字が大きいw なのに読んでみたら内容が濃い！ 読み終わって晩御飯までちょっと時間があったのでインスタで呟いたりしてました。 現場で役立つシステム設計の原則、ようやく読み終わった。大事だと思う所に付箋。 インスタは大体ツイッター連携してるので、ツイッターにも流れまして・・・。 そしたら・・・ なんと！著者さまが反応してくださって、心臓飛び出るかとw 食べてたチキンのフライ吹きそうになった・・・ どこに付箋を貼ったのか興味を持ってくださってたみたいです。 今度こちらの読書会に行く予定でして。 devlove-kansai.doorke
どこに何を書くのか?
13. type User struct { Attack int //攻撃力 } func main() { u := User{ Attack: 100, } //攻撃力は int の Attack に乱数を加算したものになる rand.Seed(time.Now().UnixNano()) u.Attack = u.Attack + rand.Intn(10) fmt.Println(u.Attack) } 14. type User struct { Attack int //攻撃力 } func main() { u := User{ Attack: 100, } //攻撃力は int の Attack に乱数を加算したものになる rand.Seed(time.Now().UnixNano()) u.Attack = u.Attack + rand.Intn(10) fmt.Pr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
集約の設計と実装
Eric Evans氏: ドメイン駆動設計は、以前より以上に妥当性を獲得している
