ドメイン駆動設計とオニオンアーキテクチャSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
「開発しない」という越境 #DevLOVE - assertInstanceOf('Engineer', $a_suenami)
このエントリは DevLOVE Advent Calendar 2014 「越境」 の5日目です。 つい先日申し込んだのに予想外に早くバトンがまわってきました。笑 前日は @azumi さんの「【マンガ】旅行サービス開発のデザイン現場へ。種を持ち帰る『越境』の旅」でした。まさかマンガとは！笑（楽しく読ませていただきました。） @azumi さんは産業技術科学大学の人間中心設計プログラムにいらっしゃるのですね。弊社の社員も現在通っていて、一緒に学んでいるようです。 さて、僕は昨年に引き続き今年も DevLOVE Advent Calendar に参加させていただきます。 昨年のエントリはこちら。 現場の反対はまた別の現場 #DevLOVE - assertInstanceOf('Engineer', $a_suenami) 自己紹介 すえなみと申します。漢字で書くと末並です。「末波」とよく間
Reactive DDD with Scala and Akka | SkillsCast
He will explain the Actor Model as an architectural style and how the basic ideas of the Actor Model and DDD can greatly simplify our ability to comprehend and use concurrency and distribution. YOU MAY ALSO LIKE: It's Just Naming Things (SkillsCast recorded in November 2022) Scala Days 2023 (Online Conference on 12th September - 11th October 2023) Getting FP Into DDD - For Real (SkillsCast recorde
シュキーンの開発とドメイン駆動設計について｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
シュキーンの開発とドメイン駆動設計について こんにちわちわ。Underbar.phpの記事ぶりになりました@emonkakです。 本エントリでは、以前のエントリでお伝えした勤怠管理アプリケーションのシュキーンの開発について述べたいと思います。 シュキーンとは シュキーンはAndroidで動作する勤怠管理アプリケーションです。打刻はNFCタグをAndroid端末にかざすことで行います。勤怠データはAndroid端末からサーバーに送信されるので、ネットワーク環境さえあればどこからでも確認することがきます。 開発のスタート 社内向けに使っていたシュキーンを一般公開に向けて改修をするということで、開発はスタートしました。メンバーは私を含む2名で進み、リリース直前に増員があり現在は3名体制になりました。今回リリースされたものは以前のバージョンからほとんど1から書き直すことになりました。 ドメイン駆動
ドメイン駆動設計読んだ - はこべにっき ♨
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (130件) を見る ドメイン駆動設計読み終った。ドメインを中心に据えてソフトウェアを設計するための方法を教えてくれる本だった。設計の話なので、抽象度が高く、なかなか読み辛いけど、良い話がたくさんでてくる。この本で例にでてくるソフトウェアが経理システムだとか貨物の配送システムなどのエンタープライズよりだったので、はじめは自分のようなWebエンジニアとっては参考にしにくいかと思っていたのだけど、まったくそういうことはなく、たいへん参考になった。 ドメイン駆動設計でいうドメインとはソフトウェアが
「ドメイン駆動設計」感想(1) - なぜファットモデルになるのか - 極北データモデリング
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (131件) を見る 正月にこれを第2部まで読んだ感想を書こうと思って、何ともう2月後半になってしまった。 いろいろ考えさせられたことを忘れてしまう前に感想文を書きます。 (DBばっかりいじっててコードを書かない)俺みたいなのから見たオブジェクト指向設計の特徴に、「実体(エンティティ)の存在は認めても、関係(リレーションシップ)の存在をなかなか認めない」、つまり関係を極力クラスとして立てない、というのがある。 例えば、部門と社員の関係を「所属クラス」として独立させるより、オブジェクト間の関連
Ruby loves DDD - ema.blog
On 14th june, in Milan, I spoke at the rubyday, and I presented a possible implementation of Domain Driven Design (with CQRS and Event Sourcing). I know quite well the principles and patterns of DDD since we used them in some applications developed by CodicePlastico, but I never tried to do the same with Ruby. The main reason of my experiment is that in C#, implementing this kind of architectures,
DDDにおいて、なぜUser#saveがいけてないのか考えてみるテスト - fusatsukatsujinのブログ
数週間前にDDD勉強会（羊）に参加したのですが（なんとじゅんいち☆かとうさんがしゃべってくれました！）、なにも成果をまとめていなかったので、その後、思ったこと考えたことを、今までの読書範囲で自分なりにまとめたいと思います。 で、テーマは一点のみで、 掲題の通り、なんでUser#saveがいけてないのかです。 ドメインを永続化する場合には、Repository に対してドメインを格納するというアプローチを取り、 ドメインに自分自身を永続化する責務を割り当てないというのがDDDです。 勉強会では、「User#saveはユビキタス言語じゃないからだめ」ということでした。 ユビキタス言語として定義されていないものをドメインの責務に割り当てるのはおかしいというわけです。 でも、よくよく考えてみると、「ユーザを登録する」という文章は成立します。 ユーザを登録するという機能自体あるわけで、違和感はそんな
ドメイン駆動設計本の読書会に参加してきた - nyanp::blog
エリック・エヴァンスのDDD本、大阪で読書会が開催されているというので行ってきた。 【限定募集：第1回の申込者のみ、参加登録可能】第２回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper 勉強会はまだ1章途中、自分で読んだのもまだ4割くらいだけど、得るものが多い本＆勉強会だと思う(主催の@kuma_nanaさんありがとうございます)。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (132件) を見る ざっくりに言うと、ドメイン(ユーザーの問題領域)のことを深く考えてソフトウェア作っていきましょうと
第二回ドメイン駆動設計読書会@大阪に参加した - hatajoeのブログ
前回とは打って変わって早起き。 午前中は娘と公園に行ってブランコに乗ったり滑り台を滑ったり鳩を追いかけまわしたりなんか白いボコボコした得体の知れない実を拾ったりした。 そんな感じで前回みたいに寝坊で遅刻することなく余裕の出発。 rebuild.fmの適当な回を聞きながら移動。ここまで超イケてるエンジニアの振る舞い。 そんなことはどうでもいい。 今回は出席者が前回の倍で17名。人数が多かったので2グループに別れての読書会となった。 流れとしては前回同様、音読からのディスカッションという形で、レポート係の方が要点をメモする感じ。 2回目だったこともあってスムーズに進行したと思う。 ただ今回も脱線というか議論は白熱して本の進捗自体は1章手前まで。 なんと2回の集会で1章に入ることもない感じ。温まって参りました！ 今回印象に残ったのは以下の２点。 DDDは別に新しいパラダイムというわけではない 昔
単体テストとMVCとDDDに対する個人的見解 - hatajoeのブログ
NOTE: 2014-01-08 追記あり。 前回のエントリでレガシーな開発環境を改善している話をした。 レガシーな開発環境の上にはレガシーなプロジェクトが存在していて、これを改善するためにどうすれば良いかを考える課程で、MVCとDDDに対する考えがまとまってきたのでアウトプットしておく。（まとまってきただけで実務レベルまではまだ落とし込めていない感） 自分が担当しているとあるWebコンテンツの話。 本題ではないので簡単に前置く。 PHP 仕様書、ドキュメント無し テスト無し 独自カスタマイズされたWAF コピペ、使用されていないソース 使用されていないテーブル、カラムの点在 Fat Controller そんな状態なわけで、当然のように日々の改修や新機能の追加でエンバグを起こす。しかも大人の事情で開発メンバーは突然入れ替わったりする。 これまでは、気をつけようとかしっかりチェックしていこ
DDD アンチパターン：賢すぎるエンティティ
Symfony Advent Calendar JP 2012 - Day 3 ドメイン駆動設計にしたがってドメインモデルをソフトウェアとして表現するのにエンティティが使われます。エンティティは、ドメイン駆動設計におけるモデル駆動設計パターンの1つに分類されます。 賢すぎるエンティティはアンチパターンRuby on Rails由来のアクティブレコードと直結したMVCフレームワークでは、本来エンティティとして扱われるべきクラスを「モデルクラス」と呼び、そこにビジネスロジック等を実装することが推奨されていました。これらのフレームワークでは、自らモデルレイヤー部分もカバーしておきながら、すべてをエンティティとして実装することを強いるため、ドメインモデルの実装にはほとんど自由度がありませんでした。 このスタイルに慣れてしまうと、ピュアなクラスでドメインレイヤーを実装できる状況においても、誤った設計
ドメインを巡るお話 | Uzzu::Blog
Jan 4 2014Tags: dci ddd 昨年末にだらだらDCIに関する自分の考えを整理したくて身内で話していて、 結論としては「DDDとDCIどちらもメンタルモデルに近づけるために機能してる点は変わらない。その先DDDあるいはDCIをフレームワークにするか、あるいは一部に取り入れるのか、そこは取組むドメインによって取捨選択だよね」というところに落ち着いたのだけれど、勿体無い内容な気がするので改めてブログに書くことにする。 DDD脳から見たDCIの考察 DCIはFATなドメインモデルに対するアプローチというよりは、シナリオを明確にするためのアプローチなのかなと思う。 DDDを実践するような複雑な問題に直面した時、ドメインモデルは山のように増える。より知識を噛み砕いてドメインモデルにしたほうがより上層のロジックが簡潔になるので積極的にドメインモデルに落とし込む方がよく、結果として、シナ
ドメイン駆動設計・モデル「深」化編・閉じた操作 - Strategic Choice
CLOSURE OF OPERATIONS貰ったものを返す俯瞰図所属するストーリの俯瞰図です。モデル「深」化どういうこと？操作の結果として、その引数と同じ型のオブジェクトを返すような操作を「閉じた操作」といいます*1。「閉じた操作」を導入すると、引数と戻り値が同じ型になるので、そこに余計な概念（クラス）を呼び込まなくて済むようになります。どうして？有用なオブジェクトの操作は、引数や戻り値の型がプリミティブ型には収まらないことが多くなります。操作の引数や戻り値に新しいクラスが登場すると、それは新たな依存関係の導入になってしまいます。どうすれば？引数の型＝戻り値の型戻り値の型が引数の型と同じにできる場合は、そのように操作を定義します。メソッドの所属オブジェクトの型＝メソッドの戻りの型メソッドの所属してるオブジェクトは、メソッドがそのオブジェクトの状態を使用していれば、そのオブジェクトは事実上メ
ServiceとDCIについて - じゅんいち☆かとうの技術日誌
面白そうなネタがあったので、自分なりの考えをまとめてみる。 Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分も返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます…。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に”サービス”って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用するためのものです。後者はドメインの知識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.yoslab.com/entry/2014/02/15/011402
sculptorgenerator.org
Vaughn Vernon氏、リアクティブドメイン駆動設計について語る
GitHub - scalikejdbc/ddd-repository-example: ScalikeJDBC example for Domain Driven Design Repository implementation.
Loading...