こんにちは。 テストエンジニアからサービス開発エンジニアにロールチェンジした、茂呂一子です。 先日リリースしました、iOSクックパッドアプリのリニューアルプロジェクトに参加し、サービス開発エンジニアとしての第一歩を踏み出しました。 今回は、アプリのリニューアルをすすめていく中で、試してみたことについて、お話しします。 アプリリニューアルの内容やそのデザイン意図については、13年続いた「つくれぽ」をリニューアルした話｜Misaki Kubosaka｜noteが詳しいので、こちらをお読みください。 リニューアルプロジェクト第1フェーズの問題点 iOSアプリのリニューアルプロジェクトは、とても大きく、機能を段階的にリリースするため、3つのフェーズに分けて開発していくことが決まっていました。 そのため、開発チームはメンバーの追加をしつつ、複数回の開発サイクル(仕様決定、設計、実装、検証)を繰り返す

ソフトウェア開発においてさまざまなアーキテクチャが提案されている中で、テストに強いアーキテクチャを紹介する本連載ですが、第5回の本稿では、「Clean Architecture」（クリーンアーキテクチャ）について解説します。 著者紹介：石黒 邦宏 デジタル・マジック・ラボでインターネット経路制御運用に関わり、オープンソースウェアで経路制御を実現する「GNU Zebra」を開発。1999年IP Infusionを共同設立し、CTOに就任。2009年Access CTO、2015年アプリックス CTOを経て、2018年デジタルハーツホールディングスCTOに就任。 「Clean Architecture」とは？ Clean Architectureはロバート・C・マーティン氏が提唱したアーキテクチャです。マーティン氏は「アンクルボブ」という通称でも知られている著名なエンジニアで、「Manifes

勉強に必要だと思う本はケチらずにどんどん買った方が良いですね。 人生の時間は有限なので、急いで目標に向かった方が良いです。 ドメイン駆動設計をなるべく早く理解できるように、入門書を読む順番を考えてみました。 最初に読む２冊 IDDD本の解説書を読む IDDD本を読む 原典に当たってみる 元祖DDD・エヴァンス本を読む 具体例から理解するDDDの入門書 実務で役立つDDD本 最初に読む２冊 IDDD本の解説書を読む 「実践ドメイン駆動設計」から学ぶDDDの実装入門 (CodeZine Digital First) 作者:青木 淳夫 発売日: 2019/05/31 メディア: オンデマンド (ペーパーバック) IDDD本を読む 実践ドメイン駆動設計 (Object Oriented SELECTION) 作者:ヴァーン・ヴァーノン 発売日: 2015/03/17 メディア: 大型本 ヴァーノン

クリーンアーキテクチャーの図を色分けして、分かりやすくした説明がありました。 https://qiita.com/anfangd/items/85409cfae73c45eaaf16 qiita.com クリーン・アーキテクチャ / Clean Architecture この同心円の図は有名だと思います。 UML図との関係で、同心円の図と同じ色で対応関係を示した説明がありました。 両者を見比べると、対応関係がスッキリして「なるほどな～」と思いました。 ついでに右下の「Flow of Control」の矢印も色分けしたUML図に書き込むと、以下のようになりますね。 この図を眺めながら、クリーンアーキテクチャーを練習してみたいと思います。 Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘

Laravelでドメイン駆動設計(DDD)を実践し、Eloquent Model依存の設計から脱却するPHPLaravelDDDドメイン駆動設計Eloquent この記事はドメイン駆動設計#1 Advent Calendar 2019の 10 日目の記事です。 2020/12/17追記 以下に続編を書きました！ LaravelにDDDを導入して1年経った所感(達成したこと / 課題点 / モデリングの難しさなど) やったこと 自社サイトのバックエンドを Laravel で実装して半年間が経ち、初期に考えた設計にいろいろと綻びが出てきたと感じていました。 そんな中、ちょうど実践ドメイン駆動設計や Web+DB Press で特集された体験 DDD を読むことができたので、さっそくいくつかの機能を DDD で実装してみました。 本記事では「もともと Laravel で実践していたEloquen

こんにちは。バックエンドエンジニアの西尾です。 スペースマーケットではAPIサイドは主にRailsを利用していますが、最近は一部サービスでNode.js+Typescriptを使い始めました。 個人的にはまだ触れていなかった領域であったのでお勉強がてら簡単なコードを書いてみたいと思っていました。 また、Node.jsの他にもう一つ最近気になり始めていたものにClean Architectureという設計思想があり、Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでいます。 本の概要は、アプリケーションが成長するに従い徐々に改修コストが上がってしまう、これを防ぐためにはうまい方法、つまり良い設計を知っている方法があるという導入から始まり、設計の歴史、原則とそれを実現するための１手段としてClean Architectureという設計思想について語られています。

こんにちは、クラウドワークスの新規事業のエンジニアとして仕事をしている高梨です！ 最近、「実践ドメイン駆動設計」という本を読みました！ 500ページ近くもある技術書で、なかなか量は多かったのですが、DDDがどんなものなのか一通り大枠を掴めた気がします。 ただ読み終わった後にこんな疑念や不安をいだきました。 「たしかにかなり面白そうだけど、実際にやるとどれだけ工数かかるんだろう...？」 「設計の話は全然出てこなかったけど、DDDで作るとなるといったい何から始めればいいんだ？」 「戦術についての知識はついたけど、実際に書こうとしたらできなそうだな...」 そこで、そういった疑念や不安を解決するために、実際にDDDでサンプルプロダクトを作ってみようと思ったわけです。 実際に作ってみるのが、結局一番理解が進みますしね。 今回は、そのプロダクトがリリースされるまでの過程や感想を、作成した設計書やソ

要約 / inb4 tl;dr DDD（ドメイン駆動設計）について調べ始めたら、解説記事でお腹いっぱいになった。 更に、一緒に語られるアーキテクチャも整理したい欲が出てきた。 Layered Architecture Layered Architecture with DIP (Dependency inversion principle) Hexagonal Architecture Onion Architecture Clean Architecture こういった経緯で、元になった書籍や記事をまとめてみた。 ちょっとしたまとめも書いた はじめに 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んで DDD入門をしてみて、ボトムアップで作り上げるときの アーキテクチャ に興味が湧き、今後、調べていくに当たって最初に見るべきであろう情報をまとめてみました。

要約 / inb4 tl;dr 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んで DDDの初歩 について学んだら、以前から気になっていた Clean Architecture についての記事も理解しやすくなった。 Laravelで実践クリーンアーキテクチャ - Qiita Laravelでクリーンアーキテクチャ - Qiita 前回の記事で実装したディレクトリ構成を改めて見直した。 前回の記事：Laravel - 『ドメイン駆動設計入門』を読んで Laravel を使って実装してみた - Qiita それっぽい構成が出来たので、今後実装する時のために思考を整理してみた。 はじめに 前回の記事 でも書いたのですが、2020年2月9-11日に開催された PHPerKaigi2020 に参加してきました。 PHPerKaigi 2020 ここで以下の本を知り、DD

要約 / inb4 tl;dr 成瀬允宣さん（Twitter , nrslib ）の 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んでサンプルコードを Laravel で実装してみた。 DDD 入門として、とても良い書籍だったのでオススメ。 実装の前提条件やポイントをまとめた。 ※注：この記事は、あくまでサンプルコードの書き起こしと整理のみです。DDD 本来の設計作業についての記載はほとんどありません。 コードはこちら anfangd/laravel-ddd-sample-for-beginners - GitHub はじめに 2020年2月9-11日に開催された PHPerKaigi2020 に参加してきました。 PHPerKaigi 2020 こういうイベントごとには滅多に参加してこなかったのですが、今回は少し足を伸ばして練馬まで行ってきました。 沢山学

PHP で DDD（ドメイン駆動設計）をする案件でウェブフレームワークの選定を行いました。 フレームワーク選定にあたり、以下の方針を立てました。 実績のあるフレームワークから選定（Laravel か Symfony の２択としました） DDD が提唱している不変条件をモデルに実装出来ること フレームワークと戦わない（目的達成の為に Hack 等の小細工をしない） 人がレビュー等で注意するといった回避策で妥協しない なるべくシンプルにフレームワークを使う 本来、フレームワークはドメイン層に関心がなく DDD に制約を与えないはずです。 一方で DDD はドメイン層以外には具体的な実装方法を提示していません。 DDD をやるのにどのフレームワークを使ってもいいのでは？と思うのですが、実際にはそうではありませんでした。 フレームワークが採用している ORM によって DDD しやすいものと困難な

Rails で DDD をしている時の集約の実装方法を考えます。 ActiveRecord と集約を別として考える メリット 集約が PORO (Plain Old Ruby Object、素の Ruby) で実装できる 集約にDB へのアクセスロジックが混在せず、ビジネスロジックの実装に集中できる デメリット ActiveRecord のインスタンスが別に作成されるのでメモリの使用効率が悪い 集約へ再構成を行う実装コストがかかる (ライブラリがあるかも) 方法 ActiveRecord のインスタンスは DAO として捉えます。 DAO はテーブルに対して操作をおこなうインタフェースとして考えればよく、リポジトリから使用することが想定されます。 例えば、作成や更新を行う リポジトリ#save を実装する場合には以下のようになります。 class UserRepository def sa

Rails でドメイン駆動開発 (DDD) をしたいという時に、考えたディレクトリ構成案です。 開発をしながら改善をして、なるべく Rails と仲良く共存できる形になったのでメモとして残します。 アーキテクチャ オニオンアーキテクチャ 参考: https://qiita.com/little_hand_s/items/2040fba15d90b93fc124 その他前提 複数のコンテキストは含めない なるべく Rails の機能を無効化しない (目標) app/ # いつもの app ディレクトリ ┣ controllers/ # アダプターとしてみなす ┣ models/ # アダプターとしてみなす ┣ mailers/ # アダプターとしてみなす ┣ views/ # アダプターとしてみなす ┣ view_models/ # アダプターとしてみなす ┃ ┣ services/ # ア

DDDに関する情報が集まっています。現在1043件の記事があります。また867人のユーザーがDDDタグをフォローしています。

Kei Sugimoto, “Two Domain Models - An Implication of DDD”, PHP Mentors, (December 20, 2015)  ドメイン駆動設計（Domain-Driven Design: DDD）は、オブジェクト指向、デザインパターン、リファクタリングなど、ソフトウェア設計分野における幅広い知的遺産と交差します。それゆえ、ドメイン駆動設計は、ドメイン指向のアプリケーションソフトウェア開発に馴染むような仕方でこれらの知識資産を統合したものと見ることができます。 こうした見方は妥当でかつ生産的でもありますが、DDDの業績に対しては別の見方もあり得ます。それがこの短い論考のテーマです。 この文脈において、DDDは、「ソフトウェア設計」から、私たちが特別な思い入れを込めて「情報設計」と呼ぶものへの静かな出発として考えることができるかもし

社内交流会でLTをする機会があったので「ユビキタス言語」についてDDD本を再度読みなおしてみました。 speakerdeck.com 最近、「DDDは負け犬」みたいな話が少しバズりましたが、ユビキタス言語＝ユーザの言葉と解釈するのはあまりに勿体無いのではないかなと思います。 ユビキタス言語はより良い・深いモデルを探求するために必要なものです。 スライドの補足 第2章はスライドに書いたことよりも、もっと多くのことについて言及されています。 ここでは、それらの省略してしまった部分を補足しつつ、スライド構成の今ひとつだった部分を正したいと思います。 まず、第2章最初の一文 しなやかで知識豊富な設計を行うには、用途の幅広い、共有されたチームの言語と、その言葉を使った活発な実験が必要である。 – 書籍「ドメイン駆動設計」(p.24) 省略しようがないくらいに、この一文に詰まっているのですが、スライド

この記事は、ドメイン駆動設計 #1 Advent Calendar 2018の10日目です。 ユビキタス言語は大事 DDDは分類手法の一つという側面があります。 分類の道具は境界づけられたコンテキストと、ユビキタス言語です。 境界づけられたコンテキストで、システムの対象業務を分類し、境界づけられたコンテキスト内部ではユビキタス言語で言葉を分類します。 個人的に、ユビキタス言語はDDDを実践する上でとても大事なテクニックだと思うのですが、何を指すものなのか、どういうメリットがあるものなのかわかりにくいために、初心者にとってはわかりにくいものかもなー、とも感じます。 そこでこの記事では、ユビキタス言語についての私の知見を書いてみます。ユビキタス言語についての学習の助けになれば幸いです。 ユビキタス言語とは何か？ ユビキタス言語の定義をする前に、「境界づけられたコンテキスト」について説明します。

ある出版社プロジェクトにおける事例 出版社は「書籍」と「雑誌」を制作している。制作した「書籍」と「雑誌」は、取次（※出版業界における卸のような位置付けの業態）や書店へ卸す。 「書籍」には返品があり得て、また在庫は会計上資産として扱われる。「雑誌」は返品はあり得ず、また在庫は資産として扱われない。 「書籍」には「ジャンル」という販売管理上の分類がある。具体的には下記の通り。 一般書籍 企画書籍（※雑誌と書籍の中間的なもの、書籍だが決して重版しない） 音響・映像媒体付き（※特別扱い） 成人向け（※特別扱い） 販売管理観点では、「雑誌」もある種の一つの「ジャンル」として扱っている。販売管理観点での「ジャンル」は、つごう下記5つという認識。 一般書籍 企画書籍 音響・映像媒体付き書籍 成人向け書籍 雑誌 「取引条件」という売価、支払サイト等に関わる諸条件が、おおよそ取引先（＝取次や書店）×ジャンル