ビッグローブでDDDを導入して早２年。 この２年間、ISP事業における主要なサービスをDDDで開発してきて、試行錯誤の連続でした。 今回は、試行錯誤の過程を経て生まれた、実際に実践している ・設計・実装の考え方（ドメインモデルやコード例やDB設計など） ・チーム環境の考え方（開発プロセスやチームビルディングなど） の２つを軸に現場でのリアルな体験を紹介します。 また、最後に、試行錯誤における失敗談も紹介します。 Read less
20151110 ドメイン駆動設計によるサービス開発
ビッグローブでDDDを導入して早２年。 この２年間、ISP事業における主要なサービスをDDDで開発してきて、試行錯誤の連続でした。 今回は、試行錯誤の過程を経て生まれた、実際に実践している ・設計・実装の考え方（ドメインモデルやコード例やDB設計など） ・チーム環境の考え方（開発プロセスやチームビルディングなど） の２つを軸に現場でのリアルな体験を紹介します。 また、最後に、試行錯誤における失敗談も紹介します。 Read less
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
ドメイン駆動設計のリファレンス本 | GuildWorks Blog
井上です。 現在、ドメイン駆動設計(Domain Driven Desing . 以下 DDD)を用いて開発を行っています。 DDDの参考書籍といえば、もちろん「エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本)ですが、その著者であるエリック・エヴァンスが最近(2014/9/22)「Domain-Driven Design Reference: Definitions and Pattern Summaries」という新しい本(以下 DDDリファレンス本)を出していることに気がつきました。 DDDリファレンス本とは 早速DDDリファレンス本を取り寄せてみました。８８ページと非常にコンパクトな本になっています。 内容的には、以下で公開されているPDFに新しい図や写真を追加してペーパーバックとして出版したもののようです。 DDD REFERE
Base DDD(ドメイン駆動設計） 参考文献を巡る旅
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
vol10_20140823
第10回ドメイン駆動設計読書会@大阪 目次 開催概要 discussion内容 開催概要 前回は番外編で、モデリングワークショップをやりました。 日時：2014/08/23 14:00 - 17:00 場所：市民交流センターなにわ 402号室 http://dddosaka.doorkeeper.jp/events/14089 範囲： 第15章蒸留より一部 p.414 汎用サブドメイン（GENERIC SUBDOMAINS） p.434 隔離されたコア（SEGREGATED CORE） 第16章大規模な構造より一部 p.456 責務のレイヤ（RESPONSIBILITY LAYERS） 方法：数分間黙読後、グループでディスカッション 司会担当：@kawakawa、レポート担当：@kuma_nana この日で課題にした章はすべて読み終えました。次回は読書ではなく、LT会。 discussio
チャットワークがScalaを採用する理由、これからのチャレンジ。 | チャットワーククリエーターズブログ
こんにちは！ChatWork CTOの山本です。 先日このブログにて「チャットワークの新しい開発言語とフレームワークを決める開発合宿を開催！その全貌を丸公開します。」という記事で、チャットワークがScalaを採用することを発表しました。 ありがたいことにこの記事はたくさんの方に読んでいただき、大きな反響がありました。セミナーなどでお話する時も、Scala採用について話を聞きたいと言われることが増えています。 今回は、Scala採用にいたったより詳しい背景と、現在の状況、そしてこれからのことについてご紹介できればと思っています。 Scala採用にいたった背景現在のチャットワークは、「PHP + 自社開発の独自フレームワーク」で構築されています。 もともとチャットワークの開発は、社内用のツールとして1人のプロジェクトからスタートしました。そのためあまり工数をかけることはできず、既存の社内システ
QCon Tokyo 2014 Conference セッション資料 BS4-1「Scalaを用いたドメイン駆動設計の実践ノウハウについて」
Copyright © GREE, Inc. All Rights Reserved. (Scala ) 2014/04/30 Version 1.0 Copyright © GREE, Inc. All Rights Reserved. • • 10 : F-BASIC, N88-BASIC • 20 : (x86), C/C++ • 30 : Java, Seasar2, OSS, DDD • 40 : DDD, Scala, Finagle/Trinity • • + 2 Copyright © GREE, Inc. All Rights Reserved. Copyright © GREE, Inc. All Rights Reserved. Scala DDD Copyright © GREE, Inc. All Rights Reserved. • • • 5 Copyrigh
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
Continuous Modeling - Fly me to the Luna
みなさまご無沙汰しております。僕はここの所、残業はしないまでも毎日クタクタになるほど忙しい毎日を過ごしています。どんな仕事か一言でいうと、あるプロダクトのアーキテクチャを刷新するお仕事です。今までできなかったあれやこれやを実現するために、既存のアーキテクチャを改善したり、作りなおすお仕事です。今はまだ始まったばかりで、方針を決めるために、既存のアーキテクチャ上に機能拡張してみて問題点を調査したり、どう改善するのか方針案を考えたり、実際に改善案を少しずつやってみたりしています。 このプロジェクトは、それほど大所帯ではないですが、他の会社のエンジニアさんも加わるなど、結構スキルセットがバラバラです。そのため、久しぶりにペアプロで作業を回しています。1日じゅうペアプロすると、一日の終わりの頃には頭がクタクタです。久しぶりです、この感覚。楽しい。 さて、既存のアーキテクチャを見ていくと、10年以上
ぐるぐる DDD/Scrum というワークショップをやってきました - haradakiro's blog
東北デベロッパーズコミュニティにお招きいただき、DDD/Scrumのワークショップをやってきました。 ワークショップは、DDD のモデリングのうずまきに、スクラムのワークショップでよく使うタイムボックス縛りを組み合わせて、Agile でいうところの Swarming という状態になれないかな、という目標で設計しました。 正直、１時間の枠組みで、シナリオ書いて、モデル描いて、コードも実装するのは、だいぶ大変だったと思います。ご参加いただき、ありがとうございました。 ただ、１時間を二回廻すだけでも、チーム内で駐車場を語る語彙、モデル、設計実装案は、だいぶ共有できたのではないでしょうか。そのまま、プロジェクトに突入できる訳ではありませんが、わからないことがわかっているというのは、プロジェクトを始めるときには非常に役に立つでしょう。 参加された方は、各チームの発表したモデルの中心(コアドメイン)が
ドメイン駆動設計・大規模戦略編・コアドメイン - Strategic Choice
CORE DOMAINドメインの中核俯瞰図所属するストーリの俯瞰図です。大規模戦略編どういうこと？巨大なシステムでは、多くの異なるドメインモデルが存在します。それらすべてのドメインで完璧なモデルを構築することは不可能です。優先順位を付けて、ビジネスにとって最も影響力のある「コアな」ドメインにフォーカスします。どうして？巨大なシステムは、寄与するコンポーネントの数が非常に多くなります。どれも複雑な上に、すべてが必要です。そのため、ドメインモデルの本質である「ビジネス資産」部分が不明瞭になり、おろそかになります。その設計も、すべての部分が等しく改良されるわけではありません。ドメインモデルを資産化するには、モデルのきわめて重要なコアを洗練し、アプリケーションの機能を作り出すために最大限に活用しなければなりません。しかし、高いスキルを持った開発者が魅かれがちなのは、技術的なインフラストラクチャや、
Domain-Driven Desing 15章のまとめ : Core Domain は DDD の基本プラクティス | システム設計日記
エバンスは、セミナーで、１５章の「コアドメイン」（問題の核心）は、Domain-Design Driven(DDD)本の、もっと前に書くべきだった。２章とか、３章に書くべきだった、というようなことをしゃべっていますね。 ◎ユビキタス言語 （いつでも、どこでも、業務の言葉） ◎モデル駆動設計 （絵や文で、コミュニケーション） ◎Hands-on モデラ (実際に、コードを書くモデラー） という、ドメイン駆動設計の基本コンセプトのひとつとして「コアドメイン」を力説すべきだったと。 コアドメインの効用 Core Domain を見つけ出し、そこに、モデリング、設計・実装のエネルギーを集中する。 その他の部分は、Core Domain との関係（近い？遠い？）、Core Domain にとっての重要性、という視点で整理する。 Core Domain との関係が弱く、重要でもない部分は、できるだけ
ドメイン駆動設計 実践ガイド
始めよう! ドメイン駆動設計＆マイクロサービス開発 ～C# と Azure Service Fabric で最高の DDD 開発を～貴志 上坂
DDDをScrumで廻す あるいは ScrumをDDDで廻す
QConTokyo 2013 で講演させていただいた DDDとScrumのお話の資料です。 簡単なライブモデリングもありましたが、モデリングのネタは、ワークショップのお楽しみということで、お願いします。Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
関数型言語F#を使ったDDDとCQRS
cunited.jp - このウェブサイトは販売用です！ - コーチユナイテッド コーチ ユナイテッド エンジ プライベート 採用 リソースおよび情報
ドメイン駆動設計のコンテキスト境界間でデータを共有する
マジックビーンズ
ドメイン駆動設計とオニオンアーキテクチャ
