自分の開発に対する姿勢を根本的に変えたドメイン駆動設計(DDD)。ぜひみんなにもその面白さを知ってもらいたい！と思い社内向け資料を作成、さらにSpeakerDeckにて公開としました。 たのしんでご覧ください！ 関連note記事はこちら：https://note.com/jgc_parallel…
たのしいドメイン駆動設計: 序 / Enjoy domain driven design : ZYO
自分の開発に対する姿勢を根本的に変えたドメイン駆動設計(DDD)。ぜひみんなにもその面白さを知ってもらいたい！と思い社内向け資料を作成、さらにSpeakerDeckにて公開としました。 たのしんでご覧ください！ 関連note記事はこちら：https://note.com/jgc_parallel…
スタートアップ開発 「DDDの次の一手」としてのチームコーチング｜little_hand_s
この記事はログラスDevチームAdvent Calenderの5日目の記事です。 SaaS開発のスタートアップ組織がスケールするためにこんにちは、株式会社ログラスの松岡(@little_hand_s)です。 ログラスは経営管理のSaaSを開発しているスタートアップ企業で、これまでアジャイル開発の手法としてDDD(ドメイン駆動設計)、スクラム、エクストリームプログラミングなどのプラクティスを適用しながら開発を行ってきました。 しかし、組織の規模が大きくなってきた(社員数が50人を超え、エンジニアチームも1チームから複数に分割されました)ことにより、それまでのスキルだけでは解消できない組織面の課題が生まれてきました。 そこで、今年の春から海外のアジャイルコミュニティで多く取り入れられている「システムコーチング®」という組織向けのコーチング手法を導入し、大きな手応えを感じているので、この記事では
Value Objectについて整理しよう - Software Transactional Memo
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita
TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一本槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日本でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守（あるいは鹿鳴館精神）ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基本線となりつつある、、、のか？ まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ
リーダブルコード by DDD / Readable Code by DDD
リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する
ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
![ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/468995f3b9ed8114c64ac798322572db942591ca/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20201221%2F20201221103037.png)
10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由｜ハイクラス転職・求人情報サイト AMBI（アンビ）
10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由 10年以上運用されているサービスには、さまざまな技術的な負債が発生しています。今後の継続的な改善のため、いったん新規開発を止めて4年かけて全面的なリニューアルを実施した「はてなブックマーク」の開発者に、プロジェクトの課題や解決する手法などを聞きました。 改善1つに数カ月かかるなら全てを書き換えられないか 2000年代にトレンドだった開発手法の負債 過去の開発意図を探る考古学的手法 データセンター移行も見据えて刷新しよう ドメインモデル設計とScalaとマイクロサービス化 コアロジックにはScalaを採用 きちんとしたドメインモデルによる設計と実装を継続したい 段階的なリリースとデータの移行という2つの大きな課題 求められる機能に沿ったデータベーススキーマに再構築 新旧の2システムを維持しながら
GitHub - ddd-by-examples/library: A comprehensive Domain-Driven Design example with problem space strategic analysis and various tactical patterns.
A public library allows patrons to place books on hold at its various library branches. Available books can be placed on hold only by one patron at any given point in time. Books are either circulating or restricted, and can have retrieval or usage fees. A restricted book can only be held by a researcher patron. A regular patron is limited to five holds at any given moment, while a researcher patr
ボトムアップドメイン駆動設計 前編
怖さの原因は？ 辛さの原因は？ ドメイン駆動設計の用語は２パターン 挫折した方がもう一度手に取ってみたいと思ったら、私の勝ちです C# だと比較ってこんな感じに実装します 勿論こんなこと毎回やってられませんから どうなりますか？ コードで表すと 識別子の値オブジェクトを作って（任意 その値オブジェクトを識別子にする 同じ属性でも 名字を変更しました 識別子を使います 例えば‘ MySql を使うと 注目すべきは このコンストラクタで受け取った userRepository これが InMemoryUserRepository か UserRepository かで動作が変わる アプリケーションサービスはユースケースを強く意識します ボトムアップドメイン駆動設計 前編 1. ボトムアップ ドメイン駆動設計 成瀬 允宣2018/10/23 in GMO Yours 1 2. 自己紹介 • 成瀬
[レポート]レガシーなコードにドメイン駆動設計で立ち向かった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)
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab
DDD連載記事 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっつきやすい」と考えるアーキテクチャを紹介します。 前提としてですが、完全に個人的な経験に基づく私見になります。 DDDの理論の中で、アーキテクチャに関しては「エリック・エヴァンスのドメイン駆動開発」(以下原典)と実践ドメイン駆動開発(以下IDDD)とでも異なったものが紹介されており、唯一の正解
![ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/98e9b5a157e996b99fb4d88308422b0a521c0937/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F8d3e611e6f96c01d6ea2f23e2d2a794301f2db7b%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fqiita-image-store.s3.amazonaws.com%252F0%252F30489%252F81fcfd95-2ce1-82a8-db69-8618338a5f22.png)
マイクロサービスの境界を決める「DDD」とは？ (1/2)
マイクロソフトは、Microsoft Azureでシステムを構築するためのクラウド設計パターン、アプリケーションアーキテクチャガイド、リファレンスアーキテクチャを「Azureアーキテクチャセンター」のサイトで公開している。これらのパターンやガイドは、米マイクロソフトのAzureエンジニアが実際に検証した上で構成サービス/ソフトを選定し、ユーザーにとって失敗が少なく汎用性の高いベストプラクティスをまとめたもので、現在、32の設計パターンと100以上のガイドを公開している。 日本マイクロソフトが2018年3月30日に開催したクラウドアーキテクト/開発者向けセミナー「パターン＆プラクティスセミナー」に、Azureアーキテクチャセンターのクラウド設計パターンを作成している米マイクロソフト AzureCAT patterns & practicesチームの成本正史氏が登壇。自身が作成した「マイクロサ
【勉強会メモ】関西Javaエンジニアの会(関ジャバ) '17 10月度 - radioc@?
kanjava.connpass.com 日時：2017/10/21(土) 13:30 〜 17:30 場所：エムオーテックス新大阪ビル 2F 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: Kindle版この商品を含むブログ (2件) を見る 今回のテーマは「現場で役立つシステム設計の原則」の著者である増田さんをゲストに迎えてのDDD特集。関ジャバですがScalaの話が多くてJavaの話は少なめ。Scala Kansai Summitのトートバッグを頂きました。 以前投稿済みだが「現場で役立つシステム設計の原則」は読んだものの、「理想はそうだがうまくいくのか？」という懐疑的な思いも若干あったが、パネルディスカッションを聞いてみると結局のところ、理論も大事だがどれだけ本気
C＃実装から見るDDD(ドメイン駆動設計)
わんくま同盟勉強会@大阪＃６０でお話しさせて頂きました。 『C＃実装から見るDDD(ドメイン駆動設計)』を多少手直しをして、再掲載しました。Read less
どこに何を書くのか?
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（ドメイン駆動設計）界の父ともいえる増田亨さんが著した「現場で役立つシステム設計の原則」を頂いたので、早速拝読させていただきました。 本書をおすすめしたい人 本書は、システム開発で以下のような問題を抱えている人におすすめです。 既存システムのソースコードの可読性が低く、理解に時間がかかる 機能追加・改修時の影響範囲調査に時間がかかる 機能追加・改修時の工数が予想以上にかかる テストコードが書きにくいソースコードになりがち 機能を追加・改修時の影響範囲が大きくなりがちで、テスト工数がかさんでいる デグレの確認に気を使い、多くの時間をかけている 不具合が発生したときに、調査・解決に時間がかかってしまう 新しいメンバーがプロジェクトに参画した時に、業務知識を伝えるのに多くの手間がかかる これらの問題のために、生み出す価値以上に、仕事時間が増えている このような問題を解消し、変更に強い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository
劇的ビフォーアフター〜BIGLOBEのDDDの昔と今〜 in 大阪
ドメイン駆動設計の正しい歩き方
(旧版)DDD × CQRS 更新系と参照系で異なるORMを併用して上手くいった話