ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ - Qiita
この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行 を超えるモノリシックRailsアプリになっています。 開発生産性が低下してきています 。 生産性低下の課題を解決しようにも、大規模な上に複雑かつ密結合な構造になっており、 マイクロサービスへの移行も、リプレイスも困難な制約 があります。 そこで半年前にリフ
DDDとコードとしての正しさ - pospomeのプログラミング日記
ドメイン駆動設計 #1 Advent Calendar 2018の14日目を担当する@pospomeです。 今回はDDDとコードとしての正しさについて書いてみようと思います。 DDDは設計手法である コードとしての正しさ コードとしての正しさを見失う ユースケースの日本語を"そのまま"コードに落とし込もうとする 無駄にオブジェクト同士の結合度を上げる RubyのActiveRecordの正しさ コードとしてのメリット、デメリットを具体的に考えて解決する まとめ DDDは設計手法である DDD = ドメイン駆動設計 ですよね。 "設計"という単語が付いていることから分かる通り、DDDはあくまでソフトウェアにおける設計手法です。 そのためDDDの成果物は"コード"であり、DDDの目的は"コードの可読性を上げること"であると自分は考えています。 DDDが持つ"ビジネスを理解する", "ドメインを
ドメイン駆動設計について DroidKaigi 2017 で登壇しました。
長らく Y.A.Mの雑記帳というブログでAndroidの技術情報を発信しています。最近はなかなか投稿できなくなってしまいましたが、それも仕事としてAndroidに関われているためです。Androidを触り始めたころはまだ学生だったので時間があったんでしょうね。 はじめて Android に関するエントリを投稿したのは 2009 年 5 月 24 日です。当時はJavaFXを触っていたので、NetbeansでAndroidをやろうとしていたようです。 当時のAndroidのバージョンは1.5、Fragment もなく、Support Library もなく、マルチタッチすらなく、ストアは Google Play ではなく Android Market という名前でした。 ここから2、3年くらいは、仕事でAndroid アプリを開発している人はもっぱらメーカーのプリインアプリを作っている方たち
システムをマイクロサービスに分解するには
２年前、Vladik Khononov氏とそのチームはマイクロサービスの導入を決定したものの、数ヶ月後には大きな混乱に陥った。モジュラリティなどの基本的な部分やその実現方法に十分な注意を払うことなく、新しいクールなテクノロジに飛びついたからだ — 先頃ロンドンのSkills Matterで開催されたDDD eXchange 2018カンファレンスで、氏はそう説明した。サーバレスフレームワークやプラットフォーム、メッセージメカニズムには投資したが、システムをマイクロサービスに分割する方法についての考慮 — バウンダリを見つけ出して、さまざまな機能がどのバウンダリに置かれるべきかを検討する過程が欠けていた。 InternovusのCTOであるKhononov氏とチームが最初に持っていたのは、サービスを小さくすればマイクロサービスになる、という考え方だった。結果は直ちに分散モノリスの構築になり、
まだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて - Qiita
＜この記事は「Money Forward Advent Calendar 2015」の22日目の記事です＞ この記事は、iOS Clean Architectureと実際にコードへ適用した内容について紹介します。 コードについては、改善の余地があるため随時修正していくと思います。 → github: https://github.com/koutalou/iOS-CleanArchitecture iOS開発においてよくある問題点 「ビジネスロジックはModelに置くべき」と言うが、開発者によって理解や意見がバラバラで統一的な実装ができない 度重なる仕様変更や複雑な仕様に対応するためにViewControllerや特定のModelが肥大化し、ビジネスロジックの本質を見失う MVC,MVP,MVVMだけで考えると、どこかのレイヤが複数の責務を持つことになり依存度の高い複雑なコードが生まれてし
わかる！ドメイン駆動設計 ～もちこちゃんの大冒険～【C91新刊】 - TechBooster - BOOTH
【C91新刊（電子書籍）】 わかる！ ドメイン駆動設計～もちこちゃんの大冒険～（A5相当で60p）はソフトウェア設計手法であるドメイン駆動設計（DDD）の解説書です。 DDDの原書である「エリック・エヴァンスのドメイン駆動設計」はたいへん分厚く、読み応えがある内容です。 そこで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)
Functional and Reactive Domain Modeling 各章まとめ - Qiita
Functional and Reactive Domain Modelingとは、ドメイン駆動設計(DDD)の関数型プログラミング(FP)とリアクティブプログラミング(RP)によるアプローチを書いた本 1. 関数型ドメインモデリング：イントロダクション 変更可能なステートを避ける - 変更可能なステートは管理が難しく、非決定性につながる 参照透過性 - FPは、参照透過なモデルコンポーネントを設計する能力を提供する。モデルの振る舞いが純粋関数で構築されていることで合成性を得られ、小さな関数から大きな関数を作ることができる 自律的成長 - 関数型の設計と思考で、モデルは自律的に成長する。純粋性故にモデルは数学的に扱うことができ、推論ができる コアドメインに集中する - DDDの原則を使用してモデルを構築すると、リポジトリやファクトリといったパターンに基づいて編成されたエンティティや値オブジ
ドメイン駆動設計の道標 - sandbox
この記事は 2016年 第2のドワンゴアドベントカレンダー、20日目の記事です。 qiita.com ドメイン駆動設計に関して悩める若者に送るポエムを書いていたら長くなりました。 20日目なはずなのに今日は 12/25 ですが、お察しください。 TL;DR ドメイン駆動設計には3つの顏がある それは「哲学」「戦略」「戦術」である 「戦術」にスポットがあたりがちだが、まず「哲学」とコアの「戦略」から理解する プロダクトにおけるドメインモデルの全体像を描いてから「戦術」を検討しよう ドメイン駆動設計をどの程度取り入れるかの 「ドメイン駆動設計の適用レベル」について はじめに ドメイン駆動設計(DDD)、以前と比較して認知が上がってきたのか、よく「DDD やってるんですか?」 「DDD ってどうはじめればいいんですか?」と聞かれることがあります。そしてこの時にまず話に上がるのが、エンティティ、集
マイクロサービスとDDDをGo言語とScala+Akkaで比較したらEventSourcingの話にもなって面白かったまとめ - yoskhdia’s diary
Reactive Messaging Patterns読書会のなかで、「マイクロサービスとAkkaとGo」な面白い話題が出たので代表でまとめる試みエントリです。（結構、色々な話題に飛んでいるので難度高い。） まとめ方としては、会話ログを転記して、最後にまとめる形をとっています。また、議論と私の考えが混ざらないように所感は分けておきます。 ddd-cqrs-es.connpass.com TL;DR 要素技術（どんな言語使うとか、どんなアーキテクチャにするとか）の前に、組織やプロダクトの性格を考えて戦略を決めましょう。 そして、その中で最適と思われる戦術をとれるような要素技術を採用しましょう。 Akka良いよ。 ログ（一部抜粋） Slackからの引用のためテキストベースです。 事の始まりは、荒木さん（以下、 @applideveloper ）の発言でした。 （この記事絡みですね。 集合知で各
DDDを使ってRailsアプリをリファクタリング - Qiita
経緯 casyというインターネットを使って手軽に家事代行を頼むことができるサービスのプログラマをしています。 Webだけでなく、スマホアプリも出すことにあたり、Webアプリサーバ(Rails)から機能を切り出し、APIサーバ(Rails)を別途作成し、Webアプリの場合はWebアプリサーバからAPIサーバを呼び出し、アプリからは直接APIサーバを呼び出すような仕組みにしました。 ただ、全部の機能をAPIサーバに移すのは容易なことではなかったため、いくつかの機能はまだWebアプリサーバに残っていて、アプリよりもWebのほうが機能が多い状態となっています。 今回残りの機能をAPIサーバに持ってくるにあたり、下記２つのアプローチがありました。 1. 既存のソースコードからViewを切り離してほぼそのまま持ってくる 2. 設計を見直し、大幅にリファクタする チーム内で議論した結果、スタートアップと
ドメイン駆動設計 ～ユーザー、モデル、エンジニアの新たな関係～
1. ドメイン駆動設計 ユーザー、モデル、エンジニアの 新たな関係 ＰＨＰメンターズセミナー in ＰＨＰカンファレンス Oct.3, 2015 杉本 啓 twitter: @sugimoto_kei http://www.fusions.co.jp 2. 自己紹介 • 会計事務所系コンサルティング会社（アクセンチュア／アンダーセン）出身。 • 生産管理/会計系基幹システム構築 (スクラッチ開発, SAP R/3等) ～ 会計・経営管理領域の制度設計・業務改革 ～ パッケージソフト（連結会計）開発など。 • 2003年独立、経営管理基盤ソフトウェア「fusion_place」の開発販売・導入支援。 http://www.fusions.co.jp • 現役 Java プログラマ。OOPラブ × XPラブ × DOAラブ。 • 全然アップデートしていないブログあり。 http://hot-h
ドメインとデータ、サブジェクトとオブジェクト、および、事実は常に事実であり、真実は常に仮説である、という話 - たなかこういちの開発ノート
先日参加の「PHPメンターズセミナー」には相当に触発されました。本記事はその勢いのままに書いたエントリーとなります。 ※下記記事もご参照ください。 →《PHPメンターズセミナーに参加してきました》 〜・〜 突然ですが、下図は、視点Aから見ると対象物は四角に見えて、視点Bから見ると三角に、視点Cから見ると円に見えるという様子を表したものです。一つの同一の対象物なのに視点によって見え方が異なる、という現象を説明するのによく使われるようです。 図１：四角、三角、円の三面図 例えば、渡辺幸三氏が下記記事にて、ご自身の「三要素分析法」を説明するのに用いています。『一つの開発対象システムだが、「データモデル」、「機能モデル」、「業務モデル」の三つの異なる視点、観点がある。各観点での設計をそれぞれ行って擦り合わせることで、対象システムの実体が浮かび上がる。』、、、このような趣旨の説明をされています。 I
戦術的DDD基本原則まとめ - Qiita
DDDを実践し始めてまだ日が浅いので、ドメインモデリング中に 細かい原則がすぐ出てこなくて迷うことがあります。 そこで、「エリック・エヴァンスのドメイン駆動設計」から 第2部「モデル駆動設計の構成要素」を中心に、モデルを表現する各要素（パターン）の 基本原則をまとめてみます。 第5章「ソフトウェアで表現されたモデル」 関連 ENTITIES（エンティティ） VALUE OBJECTS（値オブジェクト） SERVICES（サービス） MODULES（モジュール） 第6章「ドメインオブジェクトのライフサイクル」 AGGREGATES（集約） FACTORIES（ファクトリ） REPOSITORIES（リポジトリ） 関連 関連をたどる方向を強制する 限定子を付けて多重度を減らす ドメインにとって本質的でない関連を除去する 本質的でない関連が除去された結果、残った関連はそのドメインの特徴を表す E
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository
Realworld Domain Model on Rails
DDD失敗談を話して学んだこと
似非サービスクラスの殺し方 / #ginzarb
ドメイン駆動設計基礎講座〜戦略編〜
実践に向けたドメイン駆動設計のエッセンス
