2016/07/23 フロントエンド関西開催のDDD勉強会での発表資料です。(一部加筆あり。) フロントエンドにおける情報設計 と DDD 座談会 - connpass http://kfug.connpass.com/event/34131/
react-native meetup #2
ddd-zk.connpass.com DDD座談会のパネラーとして登壇させていただきました。 素振り 予め参加者の方々からいただいた質問(テーマ)に対して、予行練習というか、ちょっと自分の考えを先にまとめていたのですが、予想通りテーマひとつひとつが盛り上がったので全部を話しきることができませんでした。 折角なのでここに公開しておきます。 ところどころ、座談会終わっての後書きも追記しています。 なお、あくまで私見ということでよろしくお願いします。座談会のまとめ記事というわけではありませんので、悪しからず。 各人のコンテキストで、こんな解釈あるよ等あると思いますので、Twitterでもコメントでもフィードバックいただければ幸いです。 DDD全般について DDDに向いている要件とは?費用対効果ってどうなの? 継続的に投資したいプロダクトであることが大事だと思っています。 システムは一度作れば費
社内交流会でLTをする機会があったので「ユビキタス言語」についてDDD本を再度読みなおしてみました。 speakerdeck.com 最近、「DDDは負け犬」みたいな話が少しバズりましたが、ユビキタス言語=ユーザの言葉と解釈するのはあまりに勿体無いのではないかなと思います。 ユビキタス言語はより良い・深いモデルを探求するために必要なものです。 スライドの補足 第2章はスライドに書いたことよりも、もっと多くのことについて言及されています。 ここでは、それらの省略してしまった部分を補足しつつ、スライド構成の今ひとつだった部分を正したいと思います。 まず、第2章最初の一文 しなやかで知識豊富な設計を行うには、用途の幅広い、共有されたチームの言語と、その言葉を使った活発な実験が必要である。 – 書籍「ドメイン駆動設計」(p.24) 省略しようがないくらいに、この一文に詰まっているのですが、スライド
DomainEvent ドメインエキスパートが「…した『とき』に、こうなる。」とか。 何かの状態変更をトリガーにして、別の処理をしたい場合にドメインイベントを使う。 イベントオブジェクトがイベントの情報を運んでくれる。 source data & processing data Domain Event ドメインイベントはイミュータブルな「source data」とミュータブルな「processing data」で構成される。 source dataってのは「イベントが発生した」という部分の情報で、これは一旦作成されたら変更されることはないよね。 processing dataは「システムがこのイベントをどうしたか」って情報ね。分けてもいいかもね。 Aggregate & DomainEvent DDDでは、1つのユースケース(トランザクション)で触ってイイ集約は1個だけ。なんだよね。 だ
昨日飲みながらドメイン駆動設計(以下、DDD)についてしゃべっていて思ったことを書く。 ドメイン駆動設計(DDD)って? DDD とは何かという説明についてはぐぐったらたくさん出てくると思うので割愛。 Wikipedia の引用だけしておきます。(雑) ドメイン駆動設計 - Wikipedia ドメイン駆動設計(英: Domain-driven design, DDD)とはソフトウェアの設計手法であり、'複雑なドメインの設計はモデルベースで行うべきであり'、'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき'とする。この名称は Eric Evans が同名の著作で用いた。 興味がある人はこちらを読んでください。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェ
DDDではリポジトリに対してDIPを利用し、インターフェースと実装を切り離す傾向にある。 これはいわゆる「抽象に依存せよ」ってやつなので、 DDDというよりは既存のプログラミングテクニックになる。 で、これを実現するためにリポジトリを以下のようにインターフェースで実装する。 コードはTypeScriptです。 interface UserRepo { insert(user: User, master: DbMasterConnection): Promise<User>; findByName(name: string, con: DbConnection): Promise<User>; findById(id: number, con: DbConnection): Promise<User>; }リポジトリの実装自体はインフラレイヤに置く。 「データを取得する」ということなので、個
1. ULS Powered byCopyright © 2015 UL Systems, Inc. All rights reserved. Proprietary & Confidential 概念モデリング再入門 + DDD ~今さら聞けない人のための基礎講座~ ウルシステムズ株式会社 河野 正幸 情報システム部門を「強く」し、次世代リーダを育成する 2. ULS Copyright © 2015 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 概念モデリングやってますか? システム化の対象業務や問題に対して深く本質的な理解を得る 上で概念モデリングは非常に有効な活動 河野の場合は概念モデリング抜きにシステム化の検討をすることはもは や考えられないほど、自分の中に定着してい
Private content!This content has been marked as private by the uploader.
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く