[B! ddd] manabouのブックマーク

『モデリングの学び方：座談会』を見たよメモ - コード日進月歩

モデリングの学び方：座談会 - connpassを見たよメモです。ディスカッション形式だったので、話の流れになぞらえてまとめていきます。本日の話し手この会でメインで喋られていたのは以下の方々増田さんかとじゅんさんミノ駆動さん hirodragonさん藤岡さん原田さん高崎さん本日の趣旨説明と増田さんの考えるモデリングに関してまずは下記の資料を使いながら今日の催しの趣旨説明と増田さんの考えるモデリングに関しての話があった。 speakerdeck.com 上記の資料にもあるが以下の話が冒頭で行われた今回の話し手の属性に関しての話(共通的な部分もありつつも自社サービスを持つ人たち3人と、受託開発を主に行う人たち3人という構成) まずは前提の話としての増田さんのモデリングの考え方のダイジェスト説明効果的なモデリングの考え方（要点をうまく表現する名前を見つける、認知不可の軽減

manabou 2021/09/09

リンク

リーダブルコード by DDD / Readable Code by DDD

リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する

manabou 2021/07/08

リンク

認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏

自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。戦術的DDD的観点での関心事の分離によるメリットとはコンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。境界がなければ意図しない密結合を生みやすくなってしまう。もちろん、境界を超える

manabou 2020/10/22

リンク

ドメイン駆動設計サンプルコードの徹底解説

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

manabou 2019/04/05

リンク

[レポート]レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 #DDDAlliance ｜ Developers.IO

こんにちは。プロダクトグループのshoito(しょいと)です。 9/26(水)に開催されたレガシーコードにドメイン駆動設計で立ち向かった5年間の軌跡に参加してきたのでレポートします。当日のtwitterのハッシュタグ#DDDAllianceのツイートがTogetterでまとめられています。 BIGLOBEにおける、5年間のDDDへの取り組みと今後についてビッグローブ株式会社西秀和さんより 30年間、事業を支えてきた業務システムをDDDで刷新する。そのためには、組織的、エンジニアのレベルなど多くの問題があります。その壁をどう乗り越えたのか？そして、壁の向こうで得た恩恵とは何のか？ 5年という期間を経て、得ることのできた気づきや組織的な変化をお伝えしたいです。アジェンダ DDD導入に至るまで導入時の苦労導入による効果今後の目標 BIGLOBE販売システムについて、DD

manabou 2018/09/27

リンク

Goのパッケージ構成の失敗遍歴と現状確認

この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう

manabou 2017/12/05

リンク

ドキュメント指向DBの論理的側面と物理的制約 - DDDと絡めて - Qiita

この記事のモチベーション RDB(Relational DataBase)の歴史は長く、ノウハウも蓄積されている。関係代数という学問もあるなどアカデミックにも研究されており、国家資格である「データベーススペシャリスト」も、ほとんどこのRDBのことを扱うなど、 RDBは一定の体系が確立した技術と言える。一方で、2010年ごろより広まったNoSQL、特にドキュメント指向DBに関しては、当然ながらRDBに比べると未成熟な段階であろう。また主観だが、NoSQLは、スケーラビリティといった物理的側面にfocusが当たることが多かったのではと思う。一方で、論理的側面 = モデリングに関して、および物理的側面と論理的側面のトレードオフの関係について、議論されつくされているとは言えない。本稿では、DDD(ドメイン駆動設計)というプログラミングの論理的側面の手法を、各DBがいかに扱えるか

manabou 2017/10/03

ddd
mongodb

リンク

【書評】現場で役立つシステム設計の原則 - システム開発で思うところ

現場で役立つシステム設計の原則変更を楽で安全にするオブジェクト指向の実践技法 [ 増田亨 ] ジャンル: 本・雑誌・コミック > PC・システム開発 > その他ショップ: 楽天ブックス価格: 3,175円読みました。断片的に収集していた増田亨さん（@masuda220）の知識を理解するのに良い本だと思います。もしDDDについて調べていて増田さんのスライドなどを見て「もう少し詳しく知りたいかも」と思った人は読むことをお勧めします。良かったロジックをenumを使って表現する P60： EnumでStrategyを管理するという言い方になるのかな？確かにこういうのは分類と実装を意味ある塊に整理出来るので良さそうです。調べたら、こういうのもありました。【enum】メソッドの定義（３）−strategyパターンを使う方法 - THE HIRO Says メソッドは必ずインスタンス変数を使

manabou 2017/08/17

リンク

DDDの始め方

DDDを始めるにあたって実施したことを実例を交えて紹介しています。内容 - DDDとは何か - なぜDDDをやるのか - 実際にどうやって導入したか

manabou 2017/07/21

slide
ddd

リンク

「現場で役立つシステム設計の原則」はプログラミング設計の普遍的な教科書 - ビープラウド社長のブログ

日本のDDD（ドメイン駆動設計）界の父ともいえる増田亨さんが著した「現場で役立つシステム設計の原則」を頂いたので、早速拝読させていただきました。本書をおすすめしたい人本書は、システム開発で以下のような問題を抱えている人におすすめです。既存システムのソースコードの可読性が低く、理解に時間がかかる機能追加・改修時の影響範囲調査に時間がかかる機能追加・改修時の工数が予想以上にかかるテストコードが書きにくいソースコードになりがち機能を追加・改修時の影響範囲が大きくなりがちで、テスト工数がかさんでいるデグレの確認に気を使い、多くの時間をかけている不具合が発生したときに、調査・解決に時間がかかってしまう新しいメンバーがプロジェクトに参画した時に、業務知識を伝えるのに多くの手間がかかるこれらの問題のために、生み出す価値以上に、仕事時間が増えているこのような問題を解消し、変更に強い

manabou 2017/07/18

リンク

Domain-Driven Design & REST

Slides of the talk I gave at Spring I/O 2016. @springcentral

manabou 2017/04/10

リンク

【D3 公開用】ドメイン駆動設計とscala 〜既存プロジェクトへの適用〜

6. 自己紹介 6 角谷文康（すみやふみやす） @FScoward ■ 略歴 2011年4月～ 2015年7月 TIS株式会社にてクレジットカードシステムの保守開発・新規開発などに従事 - 2014年2月デブサミ2014登壇 2015年8月株式会社ビズリーチ入社 2015年8月～ 2015年12月スタンバイのサーバーサイドエンジニア 2016年1月～現在 HRMOS採用管理のサーバーサイドエンジニア 2016年12月（予定） JJUG CCC ■ 好きなものスフィア、乃木坂46、欅坂46

manabou 2017/01/26

リンク

実録!!データ構造リファクタリング -- 僕とメッセージ機能の300日戦争 - Qiita

みなさんもきっとそうだと確信いたしておりますが、プログラマというのは、どういうわけか実装のちょろまかしには頭がまわるもので、今や丁寧なコードを書く人の鏡とまで言われるワタクシも、それはそれは手抜き方法ばかりうかんだものでした。技術的投資のいくつかは、不本意ながら技術的負債になりまして、いろいろと世間様にもご迷惑をおかけした次第です。みなさんもきっとそうだと思いますが。この話は、そんな「誰にでもある」小さな事件のひとつです。1 この記事は CrowdWorks Advent Calendar 21 日目の記事です。昨日は @tmknom さんの「アプリケーションアーキテクチャに関するポエム」でした。設計に関するトピックは幅広く、かなり広範な知識が求められますよね！早く DDD を読まねばという気分になりました（笑）。さて、この記事は、著者がここ１年ほど携わった簡単なデータ構造の

manabou 2017/01/18

リンク

苦悩と喜びを与えてくれた[エリック・エヴァンスのドメイン駆動設計]をまとめた - Qiita

はじめに [エリック・エヴァンスのドメイン駆動設計]この本をエンジニアであれば聞いたことや見たことある方はいるのではないでしょうか？私も良本という噂だけは知っていたので、一度は読んで読んでおきたいなと思い今回読みました。私の性格的に、サーっと流し読みはできない性格(流し読みしたところに良いことが書いてあると勿体無いので)なので、しっかりと１文字づつ読んでます。読んで見て思ったことは、はっきり言って難しすぎる、それなりに設計に関わる技術書は読んでますが、飛び抜けて難しいです。言い回し、例題、語彙、全てにおいて難しいです。少しでも気を抜くと何言っているのか分からなくなります。全く中身のないことを、それっぽく言っているだけなのではないかと錯覚をするほどです。このTED Talksを思い出しました。 [ウィル・スティーヴン「頭良さそうにTED風プレゼンをする方法」] https://

manabou 2017/01/18

ddd

リンク

ドメイン駆動で開発するラフスケッチから実装まで

4. 拙い設計 • コードが重複しまくっている • 条件分岐の密林があちこちにある • どこに何が書いてあるかわからない • 変更した時にどこで何が起きるか推測できない • やっていることは解読できるが、なぜ、そこでその処理が必要か意味がわからない • パッケージ名/クラス名/メソッド名/変数名/コメントが嘘だらけ • でも動いてる動いていなければ、ろくでもない設計であることは誰でもわかるのに… 4 5. 善い設計 • コードの重複がなくなる • 条件分岐の密林がなくなる • どこに何が書いてあるかわかりやすくなる • 変更した時に影響範囲を限定しやすくなる • 処理の意図がすぐわかる • パッケージ名/クラス名/メソッド名/変数名がわかりやすく正確になる – コメントはむしろノイズ 5 ドメイン駆動設計を実践すると、自然にこうなっていく

manabou 2016/11/03

リンク

DDDパターンを活用した Laravelアプリケーション開発/ddd-with-laravel

2016/10/29 Laravel Osaka 2016 http://php-jp.github.io/laravel-osaka-2016/

manabou 2016/10/30

リンク

パーサを駆使して未使用コードをガンガン削除！削除駆動開発（DDD）徹底入門 #RubyKaigi #RubyKaigiB

Chris Arcand @chrisarcand Engineering Lead @HashiCorp, Terraform Cloud 👨‍💻 ex-@redhat, @sportsengine. Aspiring recluse. I used to play the clarinet A LOT. He/him. https://t.co/tHn1eZSEso Chris Arcand @chrisarcand Slides from my talk “Deletion Driven Development” are now up! Go out and delete some code today! ✂️🔥 chrisarcand.com/talks/deletion… #RubyKaigi 2016-09-10 14:37:05 リンク Speaker Deck Del

manabou 2016/09/13

リンク

【保存版】Scala/Scrum/DDD 困ったこと50連発ガトリングトークでの質問に対する回答 - FLINTERS Engineer's Blog

こんにちは。 @kimutyam (木村)です。先日は『Scala/Scrum/DDD 困ったこと50連発ガトリングトーク』という勉強会にて登壇させていただきました。 scala-scrum-ddd-gatlingtalk.connpass.com 登壇後はガトリングすぎたのであっという間に終わったという意見がありましたので、勉強会で質問していただいた内容の回答をまとめるエントリとします。勉強会内容について Scala/Scrum/DDD 困ったこと50連発ガトリングトーク！！ from Yasuyuki Sugitani www.slideshare.net 50連発でもスライド数173枚到達しました。元々は100連発にしようと目論んでいたけど辞めてよかった... 以下のカテゴリで困ったことを50連発して各社でどのように解決してきたかというのが、このイベントの趣旨です。詳細はス

manabou 2016/08/23

リンク

マイクロサービスとDDDをGo言語とScala+Akkaで比較したらEventSourcingの話にもなって面白かったまとめ - yoskhdia’s diary

Reactive Messaging Patterns読書会のなかで、「マイクロサービスとAkkaとGo」な面白い話題が出たので代表でまとめる試みエントリです。（結構、色々な話題に飛んでいるので難度高い。）まとめ方としては、会話ログを転記して、最後にまとめる形をとっています。また、議論と私の考えが混ざらないように所感は分けておきます。 ddd-cqrs-es.connpass.com TL;DR 要素技術（どんな言語使うとか、どんなアーキテクチャにするとか）の前に、組織やプロダクトの性格を考えて戦略を決めましょう。そして、その中で最適と思われる戦術をとれるような要素技術を採用しましょう。 Akka良いよ。ログ（一部抜粋） Slackからの引用のためテキストベースです。事の始まりは、荒木さん（以下、 @applideveloper ）の発言でした。（この記事絡みですね。集合知で各