この記事は、ドメイン駆動設計 #1 Advent Calendar 2018の9日目です。 明日は@kmdsbngさんです。 今回は、ドメイン駆動設計（以下DDD）を学ぼうとする人に対して参考になる資料をまとめます。 DDD関連資料のオススメ まずはDDDの青い本、エリック・エヴァンスのドメイン駆動設計から手を出したいところですが、500ページ超えで分厚く、初学者の人とっては解説される内容が抽象度が高く、理解するのに苦労すると思います。 ですのでこれから紹介するSTEPの順番から読んでいくのことをオススメします。 STEP1 まずはDDDの概念から理解していくことから始めましょう。下記の本がオススメです。 わかる！ドメイン駆動設計 ～もちこちゃんの大冒険～ https://booth.pm/en/items/392260 この本はストーリー形式でDDDを解説されていますので比較的理解しやす
2. DDD(ドメイン駆動設計)とは ドメイン駆動設計（DDD: Domain-Driven Design）とは 2003年にEric Evans氏が提唱した「顧客と開発者が業務 を戦略的に理解し、共通の言葉を使いながらシステム を発展させる手法」です。 DDDの登場から15年以上が経ち、DDDは着実に普及し つつあります。 本セッションでは、2013年にVaughn Vernon氏が発表 した書籍「実践ドメイン駆動設計（通称：IDDD）」の 流れに沿って、DDDの基本からモデリング手法までを 幅広く紹介します。 3. IDDD(実践ドメイン駆動設計)とは 原書名：略称（日本語翻 訳名） 著者（翻訳・監修） 原書発売年 （日本語版発 売年） 内容 日本語版の 総ページ数 Domain-Driven Design - Tackling Complexity in the Hear
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 設計するとき、「このオブジェクトの責務は何だろうか？」とか「この責務に名前をつけるなら何か？」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。 責務とは 困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven desi
ChatWork Advent Calendar 2017の10日目の記事です。 こんにちは。かとじゅん([Twitter:@j5ik2o]) です。 何を書こうかと悩んだのですが、社内で意見を聞いたところ、やはりDDD関連がよいとなりました。 Scalaコードでわかった気になるDDD この記事も、もう四年前ですっかり古くなりました。最近どういう観点で実践しているかまとめてみます。(DDD初級者という方は、まず上の記事を読むことをお勧めします) DDDを実践するにあたっての個人的な問題点は2つあります。ひとつは、「いきなりドメインモデルを作ることができない」という問題。もうひとつは、ドメインモデルを作り上げても実装コードに役に立つ振る舞いが思いつかず、いわゆる「ドメインモデル貧血症*1」になりやすいという問題です。このような問題は、僕がコミュニティで関わった多くのエンジニアから耳にします。
この記事はCrowdWorks Advent Calendar 2017の4日目の記事です。 はじめに 今年CrowdWorksにエンジニアとして新卒入社した@kinakoboです。CrowdWorksでは10月から新たな試みとしてドメイン駆動設計（DDD）を実践しています。 DDDを実践するに至った経緯は、サービスの規模拡大に伴いアプリが肥大化し、技術的負債が増えてきたことで、機能追加をスピーディーに進めづらくなってきたからです。 今回実装しようとしている機能を今まで通りRuby on Railsを利用して実装することは可能ですが、変更に強い柔軟なサービスにするためにもDDD+Scalaで実装し始めています。 DDD未経験の状態から2ヶ月実践してみて、まだ道半ばですが感じたことを書きます。同じような課題感を持っている方の参考になれば幸いです。 エヴァンス本に挫折したら･･･ DDDと言え
10. 学んだことをコードで表現する • ドメインの知識をコードで表現する基本スキル • 値オブジェクト、コレクションオブジェクト、区分オブジェクト • 識別オブジェクト、集約 • Repository, Factory • 知識の増加がコードに現れる • パッケージ名、クラス名、インタフェース名、メソッド名 • 洞察の深さがコードに現れる • パッケージの構造、オブジェクトの参照関係、… • コードレビュー：ドメインの学習成果のレビュー • パッケージ名、クラス名、インタフェース名、メソッド名、… • 参照関係／グルーピングの範囲 • コードで表現されたドメインの知識の量は？ 質は？ • コードでの知識表現に工夫の余地は？ 10 技術者はエクセルで知識を表現してはいけない
kanjava.connpass.com 日時：2017/10/21(土) 13:30 〜 17:30 場所：エムオーテックス新大阪ビル 2F 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: Kindle版この商品を含むブログ (2件) を見る 今回のテーマは「現場で役立つシステム設計の原則」の著者である増田さんをゲストに迎えてのDDD特集。関ジャバですがScalaの話が多くてJavaの話は少なめ。Scala Kansai Summitのトートバッグを頂きました。 以前投稿済みだが「現場で役立つシステム設計の原則」は読んだものの、「理想はそうだがうまくいくのか？」という懐疑的な思いも若干あったが、パネルディスカッションを聞いてみると結局のところ、理論も大事だがどれだけ本気
自分の指向としては、技術の勉強というとDDDとかOODとか、そういう抽象的方面が好きなのだが、オブジェクト指向否定論もあることは承知している。 ---------------追記 2020/09/27 この記事は「ユーザーのメンタルモデルを反映させる」というMVCの本来の設計思想を捉えていません。ただ、巷に流布しているものを元に考えた記事としては資料的には無価値ではないと思いますので、ログとして残しときます。 MVCの本来の考えはOOUIの本や、コプリエンのLean Architecture本が良さそう ------------------------------- 過剰設計の落とし穴 実際、レイヤー構造や業務モデルを頑張って作っているが、実装時に足かせになったり、プログラマがよく規約や方針を理解できずに、ごちゃごちゃに作り、余計に複雑になってしまったりするのは、色々聞く。（自分はこれをや
楽しかった！ DDD & Microservices with Spring Cloud 前半がこれまで僕が経験してきたDDD 後半がこれからのために素振りしておきたいこと これまで僕が経験してきたDDD 最近、組織について考えるようになってきたのもあって「境界づけられたコンテキスト」が一番大切だなって実感してる。全てを一度に相手にするのではなく、切り取られた世界を作って、その中で適用していく。その切り取られた世界の間の関係性もデザインしていく。そうすることで複雑さを手に負える大きさでコントロールできる。 DDDを知った当初は、エンジニアとしてEntityやValueObjectのところが面白いなーって思ってゴニョゴニョコード書いてたりしてたんだけど、しばらくして「もっと良いコード書くためにはその土台となるチームづくりをしなきゃ！」と思ってスクラムを導入してたんだけど、しばらくして「チーム
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #経緯 casyというインターネットを使って手軽に家事代行を頼むことができるサービスのプログラマをしています。 Webだけでなく、スマホアプリも出すことにあたり、Webアプリサーバ(Rails)から機能を切り出し、APIサーバ(Rails)を別途作成し、Webアプリの場合はWebアプリサーバからAPIサーバを呼び出し、アプリからは直接APIサーバを呼び出すような仕組みにしました。 ただ、全部の機能をAPIサーバに移すのは容易なことではなかったため、いくつかの機能はまだWebアプリサーバに残っていて、アプリよりもWebのほうが機能が多い状
単方向にする DDD には一方向の関係性が適しています。Eric Evans は、「可能な限り関係性を制限することが重要です」、そして「ドメインを理解することで自然な方向性が明らかになります」と助言しています。 - データ ポイント - ドメイン駆動設計のコーディング: データを重視する開発者のためのヒント (第 3 部) DDDにおいては 関連を極力排除する のが正しいようだ。たとえば「伝票」と「明細」からなるaggregateについて。まずaggregate rootである「伝票」が グローバルなIDをもつ 。関連は「伝票」から「明細」の向きにある。つまり「伝票」オブジェクトが「明細」オブジェクト（のコレクション）を参照する。逆はしない。「伝票」は「伝票リポジトリ」にある（リポジトリから取得する）。 class Slip { UUID id; List<Detail> details
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
