はじめに こんにちは。プロダクト開発部の荒川です。 これまで最年少を謳っていましたが、ついに新卒の子にその座を奪われてしまいました。とても残念です。 さて今回のテーマは、皆さんお馴染みクリーンアーキテクチャ（Clean Architecture）です。 クリーンアーキテクチャは一時期流行し、その流れに乗って私もある程度の理解はしていました。 しかし、それはあくまでも感覚的な理解であって、他人に説明や良さを語れるレベルまで自分の中で落としこめていませんでした。 そこでより具体性のあるソースコードを読み込むことで、アーキテクチャへの理解を深めたいと思います。 クリーンアーキテクチャとは？ クリーンアーキテクチャの定義や解説に関しては、ネット上にいくらでも公開されているので、このエントリでは詳しく話しません。 私自身が勉強に使った書籍やサイトを記事末尾の「参照」に掲載しているので、そちらを参考に
概要 ドメイン駆動設計の有名な用語にエンティティというものがあります。 ほとんどドメイン駆動設計の代名詞のひとつと言っても過言でないほどの有名さを誇るこちらの用語ですが、なんとクリーンアーキテクチャにもまったく同じエンティティという用語が出てきます。 このエンティティという用語は名前こそ同じではありますが、実は完全に同じものを指しているわけではありません。 とはいえまったく違うものである、というわけでもありません。 要するにややこしい。 この記事はこのややこしい用語について、ドメイン駆動設計とクリーンアーキテクチャのそれぞれのエンティティが何を指していて、それがどのように異なっているのかについてを解説します。 それぞれのエンティティ そもそもエンティティとは何でしょうか。 英和辞典を引くとエンティティとは「存在［実在］物」といった意味が出てきます。 これはかなり抽象的な意味です。 つまり、
ドメインオブジェクトを中心としたClean Architectureは、どういうレイヤー構成にするとよいか、簡単にまとめてみた。 イメージ たぶん、こんな感じになるはず。通常は円状に表現するが、わかりにくいので層状に書いてみた。 レイヤー構成 赤い部分の層は、直接依存の方向が上から下です。グレー部分の層は、契約だけが定義された独立した層で、ユースケース層やインターフェイス層から依存できるものとします。 インターフェイス（アダプタ）層 内外とのデータ形式の変換が主な役割 コントローラ、プレゼンター（内部から外部へデータ形式を変換する責務）,ゲートウェイ(外部と通信する責務。DBやRPC) ユースケース層 アプリーケーション層ともいう アプリケーション固有のビジネスルールをカプセル化する ドメイン層 Clean Architecture本では、中心にはエンティティとだけ書かれているが、DDDで
はじめに クリーンアーキテクチャの書籍を読んだので、実際にクリーンアーキテクチャの考え方を採用したREST APIをGO言語で実装してみた。 ↓↓↓↓ソースコード↓↓↓↓ https://github.com/yoshinorihisakawa/sample-api-hoop/tree/develop この記事ではクリーンアーキテクチャの説明というよりかは、実装ベースの実践的な内容にしている。 対象読者 ・クリーンアーキテクチャで実装されたソースコードを理解したい人 ・クリーンアーキテクチャの右下の図がよくわからない人 ・アーキテクチャについて勉強を始めた初心者 クリーンアーキテクチャとは？ クリーンアーキテクチャとは、8th Light, Inc.のブログ記事で提案されている。 一言で言うと、依存関係をコントロールし持続可能なソフトウェアを実現するための体系的な手法である。 ※ DIやD
ここからはサーバーサイドにフォーカスした大規模改修の詳細についてご紹介します。 大規模改修前のサーバーサイドの構成 当時はこのようなレイヤードアーキテクチャを採用していました。縦はController、UseCase、Repository、データ層で区切り、横はコンテキスト毎にパッケージで区切られています。当初から複雑な仕様・要件でしたが、それぞれの影響範囲は明確となっているので、新規に参画するエンジニアにとっても十分に見通しの良いものとみなしていました。 事実、この設計で２年ほどエンハンスを続けてきましたが、大きな問題が発生することはありませんでした。 なぜ大規模改修が求められるようになったのか 『TOEIC対策コース』の新設が決まり、その仕様を詰めていくうちに次のことが浮き彫りとなってきました。 TOEIC対策コースと日常英会話コースとでは『レッスン』と『トレーニング』のツリー構造が根
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2018/11/10 追記 かなり時間が経ってしまいましたが、当時の理解が甘かったところがあり、CleanArchitectureというよりも、レイヤごとに分離させたという方が適切な表現であると気がつきました。 では何をもってCleanArchitectureなのか？というのは、こちらの記事が参考になりました。 https://qiita.com/gki/items/f601afbfada85fd8624e —— 概要 自社サービスのアプリのアーキテクチャにMVVMを採用していたのですが、 ViewModelやModelが肥大化 Mの部
はじめに CleanArchitectureってなに？という話はこの辺を参照 で、CleanArchitectureの最大の問題は、きっちりやろうとすればするほど、クラス数が増えていくということ。 Kotlinを導入してせっかくコード量が減るのに、クラス数が増えることで作業が増えてしまえば、旨味が減ってしまう。 しかもAndroid-Studio(Ver3.0)の対応がまだ途中なのか、微妙にKotlinのクラス作成手順がメンドクサイ なので、解決策として、CleanArchitecture用のテンプレートを用意し、極力クラス作成に関わる作業を簡略化し、必要最低限の作業で必要なクラスを一括で作成できるようにした。 ちなみにこの記事の内容はGithubのREADMEの内容をほぼそのまんま持ってきてます。 諸々置き場 ココ https://github.com/kiuchikeisuke/And
CAMPFIRE iOS #1 - connpass https://yj-meetup.connpass.com/event/51735/ での発表資料です。 (2017/3/23追記): 各所からいただいたフィードバックに基づき、不正確な記述を修正しました。（Nyohoさん、あんざ…
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今回業務で初めてドメイン駆動設計（以後DDD）をiOSアプリへ導入してCleanArchitectureを目指してみたのでまとめとその所感をつらつらと書いてみます。 今回はたまたまiOSで導入したのでiOS前提で話を進めますがAndroidにも適用できる汎用的な概念です。 上辺だけの知識+オレオレルールで導入を始めたので間違っていたらご指摘お願いしますm(_ _)m そもそもドメイン駆動設計って？ MVCなどの概念と同じ（ちょっと違うけど）設計アーキテクチャの一つで、iOSやAndroidアプリ開発でおこりがちな、ファットコントローラー
![iOS/Androidアプリへドメイン駆動設計（DDD）を導入してCleanArchitectureを目指す [導入編] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/40af99188052dfd97b73268f4cb7b9f48d32d3fb/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGMTI5ODcyJTJGcHJvZmlsZS1pbWFnZXMlMkYxNDczNzE3NzEzP2l4bGliPXJiLTQuMC4wJmFyPTElM0ExJmZpdD1jcm9wJm1hc2s9ZWxsaXBzZSZmbT1wbmczMiZzPTY4Y2NlYTQ3NmFiYTUwOTVjZmNhMTIzZWNiMDZjYmVl%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D35a4181cb4f7fb2234e2a4b7cfdb145f%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9aU9TJTJGQW5kcm9pZCVFMyU4MiVBMiVFMyU4MyU5NyVFMyU4MyVBQSVFMyU4MSVCOCVFMyU4MyU4OSVFMyU4MyVBMSVFMyU4MiVBNCVFMyU4MyVCMyVFOSVBNyU4NiVFNSU4QiU5NSVFOCVBOCVBRCVFOCVBOCU4OCVFRiVCQyU4OERERCVFRiVCQyU4OSVFMyU4MiU5MiVFNSVCMCU4RSVFNSU4NSVBNSVFMyU4MSU5NyVFMyU4MSVBNkNsZWFuQXJjaGl0ZWN0dXJlJUUzJTgyJTkyJUU3JTlCJUFFJUU2JThDJTg3JUUzJTgxJTk5JTIwJTVCJUU1JUIwJThFJUU1JTg1JUE1JUU3JUI3JUE4JTVEJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LXBhZD0wJnM9NWJjNTM3ZTc2MTAxZDI4ZDlhZWZmMGIxYTEzY2NlNjU%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBrYXpha2FnbyZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPWU0MWY0MWQ1NmNhOTY3Yjg2ODA2MmYwNTRiYjc5NGFk%26blend-x%3D242%26blend-y%3D454%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44Kk44Kw44OL44K5%26txt-x%3D242%26txt-y%3D539%26txt-width%3D838%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25233A3C3C%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D28%26s%3D679d92c8b845c951c0600c87bdf0b8f0)
ちょっと前にiOS allstars2に参加して知ったClean Architecture(クリーンアーキテクチャ)が、最初はなるほどすげえなーと思っていたものの、ちょっと改めて調べてたら少し迷子になったので自分のために色々整理してみる。 そもそもクリーンアーキテクチャの前に クリーンアーキテクチャのことを書いているエントリーを見るとよくMVC, MVVMなどのアーキテクチャとの比較があるが、一緒に丸が４層になった絵が出てくる。（本家はこちらですが、日本語訳をされた方のエントリもある。） 自分はいきなりこの絵をみても何のことやらだった。が、この絵はオニオンアーキテクチャ、ヘキサゴナルアーキテクチャを知ると理解できた。 ヘキサゴナルアーキテクチャ (Hexagonal Architecture) ヘキサゴナルアーキテクチャは、伝統的なMVC, MVVMなどのレイヤード（階層）アーキテクチャか
はじめに こんぬづは、今年は冬コミに初参加してみようかと企んでいる田中です。秋葉原に務めるからには、その文化を身をもって味わう必要があるかと思った次第で御座います。 この記事はiOSでクリーンアーキテクチャに興味がある人が対象です。「やろうかな？」「そもそもどんなものなのかな？」と考えている人は参考にしてください。 クリーンアーキテクチャを調べると、解説記事は数多く見つかります。私は「これだけ情報があれば理解できるだろう」と思っていましたが、いろいろな記事を読めど読めど、しっくりくる感覚がなかなか手に入らない状態に陥りました。そんな経験を元に、私がクリーンアーキテクチャによるアプリ開発を学習し、実際にコードを書いていく上でとても参考になった資料を紹介します。 対象読者 そもそもクリーンアーキテクチャとは？とお思いの方 これからiOSでクリーンアーキテクチャによるアプリ開発をやってみたいと考
株式会社LITALICOでアプリエンジニア（iOS/Rails）を担当しています、shuyuheyです。 『LITALICO Advent Calendar 2016』7日目の記事です。 まえがき このエントリでは、iOSアプリをリファクタリングしながら、徐々にClean Architectureを適用していく過程で気づいたことをまとめます。 まだまだリファクタリングは途中ですし、アーキテクチャ適用の中でも手探りな部分がありますので、ご意見を頂けますと大変嬉しいです！ 当初のアプリの状態 当初のアプリでは、次のようにロジックがまとめられていました。 Managers サーバAPIへアクセスする レスポンスをModelへパースする パースしたModelの一部を、インスタンス変数で管理する シングルトンとして実装 Model JSONオブジェクトの変換先 Himotokiで実装 ViewCon
2. アーキテクチャ編の復習 質問がありましたので、ディスカッションしておきましょう。 Q.1 「オニオンアーキテクチャと同じくたまねぎのようなレイヤー構成になっているが、その意味は？」 Domain Modelをコアとしたアーキテクチャだからです。 上下ではなく、コア（interface）を実装(implement)が包み込んでいく(DI)メタファ。 Q.2 「データベースは、下位層ではなく外界とすれば、いいのでは？」 The Onion Architecture - Jeffrey Palermo http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ その通り！ “The database is not the center. It is external. ” じゃあ、センターはなに？ “Remember that
はじめに Firebaseを勉強したので、簡単なToDoリストを作ってみます。 方針 ・設計手法は、クリーンアーキテクチャを採用 ・データの管理は、FirebaseのRealtime Databaseを採用 前提知識 ・Firebaseの導入方法 ・Firebaseによる認証方法 ・FirebaseによるRealtime Databaseの使い方 ゴール ユーザごとにToDoリストを管理するアプリを作ります。 画面構成は、ログイン画面、ToDo一覧画面と、ToDo登録画面です。 （会員登録機能、ログアウト機能については、割愛します。） （１）ログイン画面 ・メールアドレス、パスワードを入力し、ログインボタンを押下すると、ToDo一覧画面へ遷移する （２）ToDo一覧画面 ・ToDo一覧を表示する ・該当行をタップするとToDoを完了済みとする（取り消し線で消す） ・プラスボタンを押下すると
![[Swift] FirebaseでToDoリストを作ってみた for clean architecture - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/5b516f6c1859d9da08ee21aafba6cfc07790f6ef/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCU3dpZnQlNUQlMjBGaXJlYmFzZSVFMyU4MSVBN1RvRG8lRTMlODMlQUElRTMlODIlQjklRTMlODMlODglRTMlODIlOTIlRTQlQkQlOUMlRTMlODElQTMlRTMlODElQTYlRTMlODElQkYlRTMlODElOUYlMjBmb3IlMjBjbGVhbiUyMGFyY2hpdGVjdHVyZSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9NDc2NmZhMzdiNWRjODc2MzA5YzY2YjAxMjE1YWU1YmQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBlS3VzaGlkYSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9M2QwYTlhNTJjNzUzNmQwOTk5NTA3NDgxZTRlMmZjZmE%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-U1RW44OG44OD44Kv%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D834144ee64c4ce86acf8b3502a7a2827)
＜この記事は「Money Forward Advent Calendar 2015」の22日目の記事です＞ この記事は、iOS Clean Architectureと実際にコードへ適用した内容について紹介します。 コードについては、改善の余地があるため随時修正していくと思います。 → github: https://github.com/koutalou/iOS-CleanArchitecture iOS開発においてよくある問題点 「ビジネスロジックはModelに置くべき」と言うが、開発者によって理解や意見がバラバラで統一的な実装ができない 度重なる仕様変更や複雑な仕様に対応するためにViewControllerや特定のModelが肥大化し、ビジネスロジックの本質を見失う MVC,MVP,MVVMだけで考えると、どこかのレイヤが複数の責務を持つことになり依存度の高い複雑なコードが生まれてし
（追記） 本記事，頭のなかを整理しきれていない状況で書いたためよくわからないことになっていますが，Clean ArchitectureやRedux，DDDの優位な点を解説するような記事ではないことをご了承いただけると幸いです． 全体の構成がどうなっているか・モチベーション・pros・cons等については後日別記事にまとめようと考えています． いま書いているアプリがClean ArchitectureになりそこねたMVPと中途半端なDDDを組み合わせたようなアーキテクチャになっている． このアプリをある程度キチンとClean ArchitectureとDDDに寄せるにあたり，DDDのレイヤ分け（Data/Domain/Presentation）をどこまで厳格にやるかで悩んでいる． 現状 だいたいこんな感じ． Data/Domain/Presentationのすみ分けはしていない 実装上は意識
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
