[レポート]レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 #DDDAlliance ｜ Developers.IO
こんにちは。プロダクトグループのshoito(しょいと)です。 9/26(水)に開催された レガシーコードにドメイン駆動設計で立ち向かった5年間の軌跡 に参加してきたのでレポートします。 当日のtwitterのハッシュタグ#DDDAllianceのツイートがTogetterでまとめられています。 BIGLOBEにおける、5年間のDDDへの取り組みと今後について ビッグローブ株式会社 西 秀和さんより 30年間、事業を支えてきた業務システムをDDDで刷新する。 そのためには、組織的、エンジニアのレベルなど多くの問題があります。 その壁をどう乗り越えたのか？ そして、壁の向こうで得た恩恵とは何のか？ 5年という期間を経て、得ることのできた気づきや組織的な変化をお伝えしたいです。 アジェンダ DDD導入に至るまで 導入時の苦労 導入による効果 今後の目標 BIGLOBE販売システムについて、DD
![[レポート]レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 #DDDAlliance ｜ Developers.IO](https://cdn-ak-scissors.b.st-hatena.com/image/square/ca7afdf4d75f0e7f31dad0cb5f52f15acfa79209/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F09%2FDDD_blue.png)
日本語のドメイン駆動設計 (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
golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? - pospomeのプログラミング日記
最近、golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? という質問を受けた。 回答時間が限られている中で質問を受けたので、 「現実的には難しい」という雑な回答しかできなかった。 さすがに雑すぎるなと思ったので、 自分なりの回答をちゃんと残そうと思う。 影響を受ける対象となるコードは? MySQL -> PostgresSQL への差し替え MySQL -> WebAPI への差し替え インフラレイヤにDB依存のコードをまるっと実装してしまう DDDの場合 独自の接続オブジェクトを作る DDD本 & IDDD本のサンプルはどうなっているか? 差し替える必要はあるのか? まとめ 影響を受ける対象となるコードは?golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? とい
「ＤＤＤ批判」への批判 - 設計者の発言
畏友である杉本氏の「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～が話題になっている。取り上げられている増田氏の著書を読んで、私もこのやり方で本格的な業務システムを開発するのは現実的でないと思ったクチである。ところがその本に関して聞こえてくるのはなにやら絶賛ばかりなので、物珍しさもあって杉本氏の批判を興味深く読んだのだが、賛同しつつも何というか中途半端な感じがした。 たとえば、ディスカウントのロジックを「数量クラス」でも「金額クラス」でもなく「受注クラス」に置くべきという指摘は適切である（じっさい私も本を読んでそう思った）。しかし残念なことに、それらの指摘が「より良いオブジェクト指向プログラミングの指針」になってしまっている。 それの何が問題なのか。私に言わせれば、そもそも業務システムをオブジェクト指向プログラミングして手に入れようとす
どこに何を書くのか?
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
DDDの始め方
DDDを始めるにあたって実施したことを実例を交えて紹介しています。 内容 - DDDとは何か - なぜDDDをやるのか - 実際にどうやって導入したか
Enterprise Architect事例紹介セミナー「ソフトウェア開発戦略史」のスライドを公開します
高校生の頃、私はシンセサイザーを購入し、ハードロックバンドのキーボーディストになることを夢見て演奏の練習をした。しかし、基礎もなく見よう見まねの独学による練習だったので、思うように上達しなかった。そこで、ふと思った。「自分が弾ける曲を作ればいいじゃん」あの頃からもう30年以上過ぎているが、このような発想は、今も私の基本的な行動原則である。現在は、ソフトウェア開発者として試行錯誤を重ね、そこで得たものを自分のソフトウェア開発戦略として実践している。この根底にあるものは、あのときと同じ「自分ができるようにすればいいじゃん」という行動原則である。このブログでは、私のソフトウェア開発戦略を、少しずつ紹介していきたいと考えている。
Functional and Reactive Domain Modeling 各章まとめ - Qiita
Functional and Reactive Domain Modelingとは、ドメイン駆動設計(DDD)の関数型プログラミング(FP)とリアクティブプログラミング(RP)によるアプローチを書いた本 1. 関数型ドメインモデリング：イントロダクション 変更可能なステートを避ける - 変更可能なステートは管理が難しく、非決定性につながる 参照透過性 - FPは、参照透過なモデルコンポーネントを設計する能力を提供する。モデルの振る舞いが純粋関数で構築されていることで合成性を得られ、小さな関数から大きな関数を作ることができる 自律的成長 - 関数型の設計と思考で、モデルは自律的に成長する。純粋性故にモデルは数学的に扱うことができ、推論ができる コアドメインに集中する - DDDの原則を使用してモデルを構築すると、リポジトリやファクトリといったパターンに基づいて編成されたエンティティや値オブジ
マイクロサービスを構築する際はイベントとDDDから始めよう
ドメイン駆動設計（DDD）は、私たちが取り組んでいるドメインに設計を近づける優れた技法だが、構造に焦点を当てすぎて、早期に設計を確定してしまうことが多すぎる。これはDDDの意図するところではない。それよりも、Russ Miles氏が「イベント - ファースト」でマイクロサービスを構築する利点を説明するなかで主張したように、ドメイン内のイベントから（設計を）始めるべきである。 Miles氏は、構造に焦点を当てることだけでなく、ユビキタス言語を特にドメインオブジェクトに集中させすぎていると考えている。より一層悪い事に、ドメイン境界を越えて再利用するために、ドメインオブジェクトを含むライブラリをも作り始めてしまい、異なる境界づけられたコンテキストが別々に発展することを事実上妨げてしまう。 氏の経験によれば、このアプローチは、エンタープライズ階層化アーキテクチャのデフォルトアーキテクチャスタイルと
ドメインオブジェクトはIoCコンテナ(DIコンテナ)に預けるな | matarillo.com
2012-07-17 19:45:12 Eric Leeの"GenesisEngine: Don’t Get Domain Objects From The Container“の翻訳。 ドメインオブジェクトはIoCコンテナ(DIコンテナ)に預けるな IoCコンテナは素晴らしいので、重要なプロジェクトではいつも使っている。しかし、IoCコンテナを使うにあたっては興味深い注意点がある。この注意点はそれほど明白なものではない。コンテナから直接ドメイン・エンティティを取り出してはいけない。 驚いたことに、このルールは出典がたくさんあるようには思えない。IoCの専門家にしてみれば割と知られていることなのに。(MLや掲示板では「やるな」というコメントを見かけるかもしれない。) しかし、コンテナからドメインオブジェクトを取り出すのがアンチパターンであるという、簡潔ではっきりした説明を見つけるのには非常
Functional DDD
Alessandro MelchioriFounder and software architect @ CodicePlastico srl at CodicePlastico srl
Domain-Driven Design (DDD)
3月19日(月)に要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いましたが、説明を端折ったところを中心にスライドの回顧をしています。 「Domain-Driven Design (DDD)」として用意した以下のスライドを説明します。 セッションの全体構成は以下のようになっています。 関数型プログラミング Object Functional Programming (OFP) Object Functional Analysis and Design (OFAD) 応用 この中で4番目「応用」は、今OOADやクラウド・プラットフォームで話題となっている技術がOFADでどのような影響を受けそうなのかということを考えてみる趣旨のセクションです。 具体的に考えてみることで、OFADへのイメージ
ドメイン駆動設計のメリットと始め方 ～ 1章「DDDへの誘い」
はじめに ドメイン駆動設計（DDD）とは、2003年にエリック・エヴァンス氏が『Domain-driven design』という書籍にて提唱したソフトウェア開発手法です。DDDを簡単に説明すると「顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法」です。具体的には、チームの共通言語である「ユビキタス言語」を用いて「ドメインモデル」を構築し、それをコードとして実装します。また大規模で密結合なシステムにならないように「ドメイン」と「境界づけられたコンテキスト」にてシステムを分割し、「コアドメイン」という最重要領域に集中して開発を行います。 ソフトウェア開発の課題とDDDが解決すること DDDの登場から10年以上が経ち、DDDは着実に普及しつつあります。DDDが普及してきている背景として、システム開発がますます多機能／複雑になり、ビジネス的にも敏速な変更が求められ
#jjug_ccc DDDとMicroservicesについて喋ってきましたー(∩´∀｀)∩ - Mitsuyuki.Shiiba
楽しかった！ DDD & Microservices with Spring Cloud 前半がこれまで僕が経験してきたDDD 後半がこれからのために素振りしておきたいこと これまで僕が経験してきたDDD 最近、組織について考えるようになってきたのもあって「境界づけられたコンテキスト」が一番大切だなって実感してる。全てを一度に相手にするのではなく、切り取られた世界を作って、その中で適用していく。その切り取られた世界の間の関係性もデザインしていく。そうすることで複雑さを手に負える大きさでコントロールできる。 DDDを知った当初は、エンジニアとしてEntityやValueObjectのところが面白いなーって思ってゴニョゴニョコード書いてたりしてたんだけど、しばらくして「もっと良いコード書くためにはその土台となるチームづくりをしなきゃ！」と思ってスクラムを導入してたんだけど、しばらくして「チーム
Railsにおけるサービスクラスのオリジナルルール - Qiita
サービスクラスとは？ Railsではビジネスロジックはモデルに実装するのが通説ですが、その原則に従うと、すぐにモデルが肥大してしまいます（いわゆる「Fat Model」）。 そこで肥大化したActiveRecordモデルをリファクタリングする7つの方法で紹介されているように、モデル以外にロジックを分離していきます。 特に「サービス」が便利で、ある一つの単位の機能をまとめて実装します。 オリジナル実装ルール サービスクラスは以下のルールで実装すると、綺麗に実装できると思います。 クラス名には動詞と目的語と「Service」を付ける 引数は出来る限りnewで渡してインスタンス化する 1つのサービスにpublicなメソッドは、原則1つにする 初期化したインスタンスはprivateのattr_readerで呼ぶ 切り分けたメソッドは全てprivateなgetterメソッドとして実装する 実際のコー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Eric Evans氏: ドメイン駆動設計は、以前より以上に妥当性を獲得している
DDD失敗談を話して学んだこと
似非サービスクラスの殺し方 / #ginzarb
普段使いのDDD
GitHub - VaughnVernon/IDDD_Samples: These are the sample Bounded Contexts from the book "Implementing Domain-Driven Design" by Vaughn Vernon: http://vaughnvernon.co/?page_id=168
