2016/10/29 Laravel Osaka 2016 http://php-jp.github.io/laravel-osaka-2016/
おはこんばんにちは、かとじゅんです。 久しぶりにブログを書く…。最近、趣味でAngular2やらReactやらやっています。やっとWebpackになれました…。 さて、今回のお題は「FluxとDDDの統合方法」について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。 Fluxって何？ まず基礎ということで、Flux i
はじめに 今日あった増田さんのDDD Allianceの3週連続DDDの話を聞いてきた所、最後の質疑応答で、 「ScalaやHaskellなんかの関数型的な考え方が適応できるんじゃないか？」 という質問が聴講者の方から上がったのですが、 増田さん的には「まだ挑戦的試みの域を出ない」という回答があったので、 ScalaでDDDを2年近くやってきた者として、これは役立つよねという手法を紹介しようと思います。 正直な話、DDDも関数型プログラミングも学ぶのに根気のいる難しい概念にもかかわらず、 バズワード化していろんな人が違う意味で使うようになってしまったので、 正直最近こういう話を書きたいと思わなくなってしまったし、 イスラムのムジャーヒディーンと十字軍の両軍の前で正義の定義について演説することに 近いものがあると思うので、気は進まないながらも、役立つものを紹介しようと思います。 まず最初に前
オブジェクト指向の「変更容易性」 (どのパラダイムでも同じだけど） • 抽象データ型／段階的な抽象化 – プログラムを人間の発想に近づけると扱いやすい •モジュラープログラミング – 独立性の高い部品に分けると扱いやすい – 関連するデータと操作は、ひとつのプログラミング単位に • メッセージング – 部品の組合せを柔軟に変更できると扱いやすい – sender/receiver/dynamic routing – Javaだとうまく実現できていないアイデア • メッセージングの考え方の参考 • Erlang, EIP:Enterprise Integration Patterns, マイクロ サービス, … LocalDate クラス 日付を汎用的に扱う手段 Java APIのレイヤ int year shortmonth short day LocalDateの内部 Java言語仕様の
どうも、ギルドワークス 前川です。 以前ご紹介した通り、ギルドワークスではドメイン駆動設計（DDD）の勉強会を社内で行っています。 その中で出てきた指摘に、ハッとする物があったので、今回はそれについて、ご紹介します。 「それ、ソースコードに書いてないじゃん」 それは、DDDを前提においたコードレビューで飛び出した指摘でした。 コードはかなりシンプルな、ユーザからの投稿とそれに関する感想を閲覧する、といったサービスに関するものでした。 こういった場合、当然のように、『”投稿”がトップレベルのオブジェクトにあり、それにぶら下がる形で”感想”オブジェクトがある』という様なモデル化をしていました。 一方このドメインにおいては、投稿もさることながら、投稿に対する感想の方がドメインにおける重要な関心事、なのでした。 それを話した時に、弊社増田の口から飛び出たのが、、、 「んで、それはソースコードの何処
いくら人の話を聞いてもピンと来ないし、DDD本を読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。 これって、ドメイン駆動設計？ from Michitaka Yumoto www.slideshare.net ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。 ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。 その世界で現状行われていること 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい) 上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが１つ。 で、ドメイン(特にいまやってる物事)を抽象化す
概要 モデリングについていろいろ - Togetterまとめを読んでいて、前にも何度か言ったことがあるけれど、もう一度言っておこうかー的な感じです。多分ブログには書いていませんでしたので。 端的に言えば、パイプ&フィルターパターンがアプリケーションドメインであるアプリケーションもあって、そういったものはオブジェクト指向より関数型的なほうがうまく適合する可能性もあるという話。 DDDとプログラミングパラダイムやプログラミングスタイルは直交するはずだ Eric Evansから提案されたDDDはクラスベースOOを主体とした実例が多かったわけですが、DDDという概念はOOを前提としていないと僕は捉えています。特に、ユビキタス言語、コンテキストの明示、モデリングと密接な開発といった部分は多くのソフトウェア開発において役立つと言えそうですし、おそらくはプロダクト開発全体でも言えそうです。 エンティティ
以前、ScalaJpのgitter.imでDDDについて議論が盛んに行われてたけど、いずれログが消えちゃうのがもったいなくて、ここに内容を貼付けます。 scalajp/public - Gitter 要約すると実践DDD本出たらみんなで読もうぜ。ってことで。 実践ドメイン駆動設計 (Object Oriented Selection) 作者: ヴァーン・ヴァーノン,高木正弘出版社/メーカー: 翔泳社発売日: 2015/03/17メディア: 大型本この商品を含むブログ (1件) を見る ホントは、自分のブログとかじゃなくてGistとかがいいんだろうけど、見た目を整えるのが一番楽なので、ここに掲載しておきます。 一応、最初にまとめるにいたった経緯↓ xuwei-k 2015年2月24日 gitter、無料だとログの保存期間2週間って話だったけど、実は現状全部残ってる https://gitte
井上です。 現在、ドメイン駆動設計(Domain Driven Desing . 以下 DDD)を用いて開発を行っています。 DDDの参考書籍といえば、もちろん「エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本)ですが、その著者であるエリック・エヴァンスが最近(2014/9/22)「Domain-Driven Design Reference: Definitions and Pattern Summaries」という新しい本(以下 DDDリファレンス本)を出していることに気がつきました。 DDDリファレンス本とは 早速DDDリファレンス本を取り寄せてみました。８８ページと非常にコンパクトな本になっています。 内容的には、以下で公開されているPDFに新しい図や写真を追加してペーパーバックとして出版したもののようです。 DDD REFERE
ハーブ栽培の品質向上を目指すスマート農業：CSIR-CIMAPにおける Mentha arvensis（ハッカ）栽培の成功事例
最近、ドメイン駆動設計ってどうやって実践すればいいかなーという質問をよくされるので、この記事が満額回答にはならないと思いますが、書いてみたいと思います。 シンプルな問題はトランザクションスクリプト、いわゆる手続き型で対処できます。問題が小さいのでコードは直接的でわかりやすくなる傾向にあります。 とはいえ、世の中の問題はシンプルなものばかりじゃない。複雑な問題もある。DDDの著者であるEric氏は、複雑な問題はドメインモデルを使って対処すべきと説く。 ドメインとは問題の領域とか知識の範囲をいうのですが、DDDはそのドメインにある概念をモデル(ドメインモデル)として定義して、さらに実装として紐付けていく設計手法です。 モデルクラスは概念ありき 例えば、電車にまつわるドメインというので考えたとしたら 電車 乗客 駅 ダイア などの概念が登場します。 現実世界に限った話ではなく、仮想世界でもドメイ
断り書き:自分たちがやりたいDDDにDoctrineが必ずしも向いていないという判断をしたものです。Doctrineには非常にお世話になっており、批判するものではありません。どのツールにも適材適所があると思います。 機械的なORMでエレガントに表現できないものがあった（ValueObjectなど） Entityが1テーブルに固く対応していて、さらにその知識がインフラストラクチャレイヤからドメインレイヤに漏れ出していて、密結合が発生していた Doctrineロックから脱出したい。Domain ServiceはRepositoryに依存しており、RepositoryはDoctrineに依存している。Doctrineが破滅への道を歩めば、アプリの心臓であるDomainも道連れとなる。 ストレージロックを脱出したい。ドメインレイヤがある具体的なRepositoryに依存していると、簡単にストレージ
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
MODULESグルーピングのモデリング別名パッケージ（PACKAGES）俯瞰図所属するストーリの俯瞰図です。アプリケーション構築どういうこと？モデルもコードも意味のある単位に分割し、モジュールとしてまとめます。プログラミングの場合と同じく、モデルのモジュール分割においても高凝集・低結合が重要な目安になります。関連し合う概念同士はひとつにまとめ（高凝集）、かつ一度に考えなければいけない範囲は最小限にします（低結合）。どうして？モデルも分割統治モジュールに分割されるのはコードだけではありません。概念も分割されます。モジュール内では高凝集、モジュール間では低結合が必要です。人が一度に考えられる物事の数には限りがありますし（ゆえに低結合)、首尾一貫していない思考の断片は理解するのが難くなります（ゆえに高凝集)。モジュールもモデルモジュールも、モデルの一部です。モデルを表現し、深化させなければなりま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
