2016/10/29 Laravel Osaka 2016 http://php-jp.github.io/laravel-osaka-2016/
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほ
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっ
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの?」 という
-----------追記------------- 仕様パターンについては以下の書籍で可能な限り詳しく解説しています。 興味あれば読んでみてください。 pospome.booth.pm -----------追記おわり------------- エリック・エヴァンスのDDD本では「仕様パターン」という実装パターンが説明されている。 仕様上のバリデーションはエンティティや値オブジェクトに実装してはいけない。 複雑な仕様による複雑なバリデーションロジックは クラスの肥大化を招いてしまう。 class User { //こういったバリデーションは肥大化を招く public boolean isXXX(){ //複雑なロジック } } また、こういったバリデーションは複数のエンティティを必要とする場合があるので、 どのクラスの責務とするのかを明確に判断できないこともある。 class User
この記事はWHITEPLUS Advent Calendar 2016 8日目になります。 こんにちは。株式会社ホワイトプラス、エンジニアの @ngmy です。 ホワイトプラスでは主に、 衣類の宅配クリーニングサービス「リネット」 布団の宅配クリーニングサービス「ふとんリネット」 靴の宅配クリーニングサービス「くつリネット」 クリーニングの保管サービス「リネット保管」 という4つのサービスのサーバサイドを担当しており、 PHP + Laravelを使用して、DDDで開発しています。 これらのサービスは、宅配クリーニングというサービスの性質上、ネットだけでなく、工場や物流といったリアルな事業ドメインも扱うことになるため、DDDのやりがいがあるサービスだと思います。 TL;DR この記事では、『エリック・エヴァンスのドメイン駆動設計』で紹介されている仕様パターンについて、架空の宅配クリーニング
ドメイン駆動設計、どこまでやるべき? 開発現場の“問題”を乗り越えるためにできること ゲーム開発におけるドメイン駆動設計とサーバレスアーキテクチャ #1/2 2019年2月7日、『神姫PROJECT』などソーシャルゲームの企画・開発を手がける株式会社テクロスが主催するイベント「TECH x GAME COLLEGE」が開催されました。渋谷発エンジニア勉強会「ヒカ☆ラボ」とコラボレーションした今回のテーマは「ゲーム開発におけるドメイン駆動設計とサーバレスアーキテクチャ」。過去にTECH x GAME COLLEGEにて講演を行ったギルドワークス株式会社取締役の増田亨氏と、Game Server Services株式会社代表取締役社長CEOの丹羽一智氏をゲストに招き、参加者から事前に募った質問に解答していただきました。前半の本パートでは、ドメイン駆動設計(DDD)やFaaSの未来、チームビルデ
jsug.doorkeeper.jp 本当に面白かった。DB周りの質疑も楽しかった。 内容は他の方のブログ参照。 これとか takeda-san.hatenablog.com 以下雑感 DDDと増田さん流のOOPを使ったアプリケーション開発 個人的にDDDというのは、アプリケーションの目的であるユーザー世界の関心毎を中心に置こう、というだけでコンセプト自体はそんなに特殊なものではなく、ソフトウェアエンジニアリングというか、プログラマー界隈では多くのグルたちが同じようなことを目指していたと思う。要するに関心毎の分離。 いくつかの重要なアイデアが発明されたけど。RepositoryとかAggregateとか、境界づけられたコンテキストとか。 いくつかの点で増田さんのやり方はエバンズが本で書いたものとはずれてたり、ポイントが違っていたりするから、DDDということではなく増田さんというプログラマー
ドメイン駆動設計の原則を体験的に学べるワークショップを開催します。(有料) 募集ページはこちら。 ↓ 実践的ドメイン駆動設計ワークショップ このワークショップの意図と内容を紹介します。 ドメイン駆動設計の3原則 ドメイン駆動設計の基本原則は、1章、2章、3章に集約されています。 ■原則その1:ドメインの知識をかみ砕く ・ドメイン(そのアプリケーションの対象領域)に関する「知識」を継続的に学ぶ ・ドメインの「知識」を広げながら掘り下げ、より深く理解する ドメインの知識の習得と理解は、どんな開発手法でも重要なテーマです。ドメイン駆動設計(あるいは、オブジェクト指向設計)では、コードを書く技術者が、自ら積極的にドメインの知識を学び続けることを重視します。 開発者が要件定義書や仕様書がでてくるのを待つのは、ドメイン駆動設計のアプローチではありません。 ■原則その2:言葉を使って意図を伝達する ・利
スタディスト開発部、フロントエンド担当の小宮山です。走ることが楽しくなりすぎてフルマラソン完走が当面の目標です。 今回は私達が進めているUIリニューアルプロジェクトにおける、フロントエンド設計の心臓部についてご紹介したいと思います。盛り上がりつつあるものの、まだまだ実践的な情報が少ないVue界隈に少しでも貢献できましたら幸いです。 画面駆動Vuexの頃プロジェクト始動当時は私含め大規模プロダクトにVuex(さらにその他Flux状態管理も)を導入して開発を進める経験も知見もほぼない状況でした。 そして開発していく画面デザインの大枠は出揃っている状態だったので、計画も実装も画面単位で区切って進みだしていきます。 こうした状況でVuexのstoreはどのような方針で実装されていくか。正確に表現するなら、特に方針なく実装していくとどうなるか。画面ファーストで、画面から使いやすく、画面ごとに専用なs
iOS/Androidアプリへドメイン駆動設計(DDD)を導入してCleanArchitectureを目指す [どうなったか編]AndroidiOSDDDドメイン駆動設計CleanArchitecture この記事は導入編の続きになります。 こっちは文字ばっかです。 実施してみて まず、そもそも私のDDDに対する理解がまだまだなので、本来の効果が発揮できているか怪しいですがNon知識から導入してみたらどうなったかということを書いてみます。 メリット1:保守性が上がった レイヤーがきれいに分かれておりレイヤー間の結合度が低いので、互いの干渉が少なく仕様変更には強くなりました。 画面単位でのロジックが一切ないので、この画面のこの処理を変更してさらにこの画面の同じ処理を…というリファクタリングはかなり減ったと感じました。 メリット2:ファットコントローラーの解消 MVCの一番の悩ましい点だったフ
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く