更新（2019年10月30日）初回投稿から3ヶ月経ちました。 この3ヶ月で新しく得た知見を基に、内容を一部アップデートしました。 今回やることGoのディレクトリ構成についていろいろと調べる中で、 こちらの資料 がとても分かりやすかったので、 今回はこちらを参考にGoでWeb APIを作っていきたいと思います。 加えて、本プロジェクトでは、DDD と レイヤードアーキテクチャー を取り入れます。 （内容はほぼレイヤードアーキテクチャになってしまいましたが…） DDD については、「DDD を Go とレイヤードアーキテクチャでやるなら、こんな感じかな？」という個人の見解レベルです。 パッケージ構成の参考になれば幸いです。 （ですので、ドメインモデルは重度のドメイン貧血症に陥っていますｗ） 釣りタイトルみたいになっちゃっててすみません🧝♀️ 環境MacOS Mojave 10.14.6Go
Clean Architecture提唱者 Robert C. Martin氏が登壇。オンラインイベント「Builders Box ON AIR ♯3クリーンアーキテクチャ」が開催
Sansan株式会社が運営する、エンジニアリング強化のためのプロジェクト「Builders Box」は、エンジニア向けオンラインイベント「Builders Box ON AIR」を、1月29日（金）に開催します。 ■開催概要 「Builders Box ON AIR」は、Builders Boxが企画する、世界に通用するエンジニアになるための知見を共有するイベントです。第3回目となる今回のテーマは「クリーンアーキテクチャ」です。 「Clean Architecture」の提唱者である、Robert C. Martin氏をゲストに迎え、エンジニアが押さえておくべきアーキテクチャやアプリケーションに最適なアーキテクチャとはどのようなものか等、広い視点で「クリーンアーキテクチャ」をテーマにお話しいただきます。 ■スピーカー紹介 Robert C. Martin（ロバート C.マーチン）氏 197
データベースの検索メソッド(リポジトリとかDAOとか呼ばれる責務のもの)をどう設計するかは、選択肢が多く考えられる。それぞれの例と判断基準について検討してみよう。 例えば、このカルーセル(carousel)みたいなものを考える。現在のRoomClipのカルーセルは、その日に投稿されたフォトを10件程度選択する仕様である。
Clean Architecture を毎日１章ずつ完読しました（PDF公開） - そこに仁義はあるのか(仮)
以前のブログで100日かけてエリック・エヴァンスのドメイン駆動設計を完読しましたと書きましたが、それに続いて Clean Architecture も完読しました！ 4/21から始まり、（家庭の都合で2日おやすみもありましたが）毎日１章ずつ、全34章を無事に完読しました 🙌 そして、今回もそれぞれの章で学んだことを毎日ノートにまとめてツイートしていきました。 Clean Architectureもかなり長い間積んでいた本だったので、やっと消費できてよかった…。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘ドワンゴAmazon ツイートはこちらのモーメントにまとめています。 今回は他の方のツイートも一緒にモーメントに追加していきました。 モーメントは100個までしかツイートを登録で
図解クリーンアーキテクチャ - Qiita
こちらに詳細に記載しています。宜しければご参照ください。 概要 一見複雑に見えるクリーンアーキテクチャをSOLID原則を用いて、成り立ちをひも解いていきます。 背景 クリーンアーキテクチャを調べていくと下記のような概念図や構成図を見かけます。 言いたいことは何となく分かるのですが、初見でメリットが理解できませんでした。 本記事ではレイヤードアーキテクチャの欠点を SOLID原則に沿って補完していくことで、クリーンアーキテクチャをひも解いていきたいと思います。 SOLID原則とは ソフトウェアの拡張性、保守性等を担保し、メンテナンスしにくいプログラムになることを防ぐための原則です。 S：SRP、単一責任の原則 O：OCP、開放閉鎖の原則 L：LSP、リスコフの置換原則 I：ISP、インタフェース分離の原則 D：DIP、依存性逆転の原則 SOLID原則の詳細はこちらの記事が参考になります。 イ
フロントエンドの複雑さに立ち向かう 〜DDDとClean Architectureを携えて〜 | さくらのナレッジ
自己紹介 さくらインターネットではシニアフロントエンドエンジニアをやっています。代表作は「NES.css」というファミコン風CSSフレームワークで、エイプリルフールには「さくらのINFRA WARS」というゲームの企画開発をしていました。 話さないこと 本記事ではソフトウェア設計ということで、以下の設計・アーキテクチャに関しては話す予定はありません。コンポーネント設計や CSS 設計に関しては過去に記事やスライドを公開していますので、気になる方はそちらを参考にしていただければと思います。 コンポーネント設計 加速するコンポーネント設計入門 / Component Design as an Accelerator コンポーネント指向時代のmargin戦略 / Rethinking the relationship between Components and Margins CSS設計 OO
【スライドあり】「PHPカンファレンス福岡」にて Laravel とクリーンアーキテクチャについてお話ししました #phpconfuk - WILLGATE TECH BLOG
ウィルゲートのアーキテクト 兼 技術広報の岡田（@okashoi）です。 梅雨で雨の日が続きますね。 雨の中を歩くと思うとちょっとだけ気分が重くなりますが、雨の日の雰囲気自体は好きだったりします。 さて以前にも記事を書いたとおり、6月29日（土）に開催された「PHP カンファレンス福岡」にて【Laravel でやってみるクリーンアーキテクチャ】というタイトルで登壇しました。 以前の記事： tech.willgate.co.jp なおウィルゲートでは地方カンファレンスに参加する際に、一定条件を満たせば「出張」という扱いになり交通費・参加費・宿泊費が会社から支給されます。 カンファレンスの様子 「Laravel でやってみるクリーンアーキテクチャ」概要 発表を振り返ってみて カンファレンスの様子 カンファレンス会場の福岡ファッションビル 当日はスタッフ・スポンサー含め述べ 268 名の PHP
【追記（2020/06/08）】 本投稿に頂いたコメントを基に加筆しました。以下に挙げた項目に対して加筆し、加筆した部分は【追記】と記載しています。 View Presenter / View Model 【追記（2020/05/31）】 同期の子から貰ったコメントを基に加筆しました。以下に挙げた項目に対して加筆し、加筆した部分は【追記】と記載しています。 SOLID原則 Form Request 新卒研修で「Laravelを使ってアプリケーションを自分で作ってみよう。」という趣旨のコーナーがあり、同期がやっていることを真似てClean Architectureを導入してみるも、無事、爆死することに成功しました。この投稿は、爆死するまでに得た知見についてまとめたものです。 この記事を読むことで得られる知見 投稿の要旨を載せておきます。 MVCアーキテクチャに愚直に沿うと、Fat Contr
ある程度複雑なiOSアプリに必要なClean Architectureのベストプラクティスを考えてみた - Qiita
読者の対象 iOSのモバイル開発において、MVC, MVVM, MVPでは手に負えなくなってきたと感じている人 動機 iOSで中大規模のアプリを作成する上で、クリーンアーキテクチャの採用する上でどういった実装がベストプラクティスなのかということをメモと勉強を兼ねて残したいと思います。 自分が考えているオレオレな解釈でクリーンアーキテクチャを理解したつもりでいるので、間違っているところが多々あるかもしれないです！ 複数の現場を経験してきて自分の考えうるベストプラクティスとして作ったものですが、ツッコミどころなどあればissueやプルリクを投げてもらえば議論させていただきたいです！ プロジェクト概要 SwiftでTodoアプリをクリーンアーキテクチャであるVIPER, View Interactor Presenter Entity Routerでつくりました。 クリーンアーキテクチャと一口に
PHP Conference Japan 2021でお話しさせていただいた、『SymfonyとDoctrineで簡単クリーンアーキテクチャ』ですが、実際にやってみようと思います。 当日のセッションはこちら やってみるユースケース 『ユーザが商品を購入する』『複数いる配送係に注文内容連絡する』っていうのをやります。 モデリング 概念モデル図 ユーザは複数の注文ができます。注文にはどの商品をいくつ買ったかがわかる注文明細が紐づいています。 配送係に連絡はするものの、注文には紐づかないので独立した形にしました。 クラス図 『ユーザが商品を注文する』というユースケースを実装するクラスと、『配送係に注文内容を連絡する』というユースケースを実装するクラスを用意します。 ここで、配送係に連絡するためには配送係を取得しないといけないので、データサービスを用意し、『配送係を取得する』処理を別途用意します。
要約 / inb4 tl;dr 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んで DDDの初歩 について学んだら、以前から気になっていた Clean Architecture についての記事も理解しやすくなった。 Laravelで実践クリーンアーキテクチャ - Qiita Laravelでクリーンアーキテクチャ - Qiita 前回の記事で実装したディレクトリ構成を改めて見直した。 前回の記事：Laravel - 『ドメイン駆動設計入門』を読んで Laravel を使って実装してみた - Qiita それっぽい構成が出来たので、今後実装する時のために思考を整理してみた。 はじめに 前回の記事 でも書いたのですが、2020年2月9-11日に開催された PHPerKaigi2020 に参加してきました。 PHPerKaigi 2020 ここで以下の本を知り、DD
参考：https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html クリーンアーキテクチャで調べるとよく出てくる例の円ですね。 ざっくり説明すると、円の中の各項目は矢印の向き（内側）に依存（参照）するようにして、特定の項目の仕様変更が他の項目に影響を及ぼさないようにしています。 それによってそれぞれが外部の項目を気にすることなくテストできたり、仕様変更の影響範囲が少なくなったりといった利点があります。 実装：クリーンアーキテクチャ化では早速、クリーンアーキテクチャ化を進めていきましょう！ Entities外側は内側の参照を持つため、内側から順に実装していきます。
クリーンアーキテクチャのお話
概要 個人開発でクリーンアーキテクチャを実装してみました。理由は、夏のインターンでクリーンアーキテクチャを採用したプロダクトに参加させていただいたため、また、復習を込めてアウトプットしようと思いました。 初投稿で荒削りかもしれませんが、この記事を訪れた方々の役に少しでも立つことができれば幸いです。 はじめに クリーンアーキテクチャといえば下図を思い浮かべる人が多いと思います。 具体的な説明は様々な人がしているため、今回は簡単に説明しようと思います。 クリーンアーキテクチャについて詳しく知りたい方へ Uncle Bob: The Clean Code Blog Qiita: 実装クリーンアーキテクチャ クリーンアーキテクチャの特徴 ボブおじさんの記事を読んでみると以下のように記述されています。 Independent of Frameworks. The architecture does
クリーンアーキテクチャや DDD の戦術的設計、CQRS などを勉強して、現状自分が気に入っているアプリケーションのパッケージ構成をさらします。 実際に Java (Spring Boot) 実装してみて、自分としてはある程度納得感を持てた構成になります。 全体像 パッケージ構成の全体像は下図の通りです。 ディレクトリで表現すると以下のようになります。 . ├── application │ ├── external │ ├── query │ │ └── user │ │ ├── UserQueryModel │ │ └── UserQueryService │ └── service │ └── user │ ├── UserApplicationService │ └── UserGetOutput ├── domain │ └── mod
GitHub - jasontaylordev/CleanArchitecture: Clean Architecture Solution Template for ASP.NET Core
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Clean Architecture は一つの選択肢でしかない PofEAA によれば、エンタープライズアプリケーションアーキテクチャにおけるドメインロジックの実装方式は以下の3つに大別できます。 Transaction Script Table Module Domain Model さらに、Domain Model については以下の２つに大別できます。 Active Record Data Mapper Active Record は Rails に代表される、Domain Object でデータアクセスをラッピングするパターン。 Data Mapper は各種 ORM に代表される、Domain Object とデータアクセスをマッピングするパターン。 この中で Clean Architecture に則ることのできるものは、Data Mapper による Domain Model
GitHub - ardalis/CleanArchitecture: Clean Architecture Solution Template: A starting point for Clean Architecture with ASP.NET Core
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
2019/10/27 (Sun) に開催された .NET Conf Tokyo で発表した、Unity で Clean Architecture を適用してみた話です。
Spring Boot2 × Kotlin × Gradle5でクリーンアーキテクチャのアプリケーションを構築する - すきま風
要旨 Gradleの勉強。クリーンアーキテクチャを実装してみます。 この記事ではgradleについて記述します。実際のコードについては次回記事を参照ください。 元ネタはSpring IO 2019で紹介されていたこちら 以前書いたレイヤーアーキテクチャのサンプルはこちら kotlin-dslで書き直したものはこちら gRPCを導入する際に書き直したものはこちら 下のサンプルほど新しいです ソフトウェアバージョン software version OS MacOS Mojave Spring Boot 2.2.0.M5 Java Corretto-11.0.4.11.1 Kotlin 1.3.50 Gradle 5.6.1 モジュール概要 module description adapters port。api, persistence, web application use case c
Keeping it simple: Cilium Mesh - networking for multi-cloud Kubernetes and beyond
はじめてのArchUnit - Qiita
今回は、2018/11に発表されたTechnology Radar Vol.19の中で自分が特に気になったArchUnitというライブラリについて書いていきたいと思います。 ゴール ArchUnitとはなにかを知る ArchUnitで出来ることを知る はじめに この記事は、公式の情報を参考にしながら実際に手を動かした結果を載せていますが、ArchUnitをつかって実装する場合はこちらの記事ではなく、公式のArchUnit User Guideを参考にするようにしてください。 また、記事の中でなにか間違っている箇所がありましたらコメントお願いします。 ArchUnitとは ArchUnitは、Java/Kotlinで書かれたアプリケーションを対象とした、アーキテクチャのテストを行うライブラリです。ArchUnitのソースコードはGitHubに公開されています。 https://github.
ターゲット クリーンアーキテクチャ 初級者~中級者 概要 WebAPI開発時はバックエンドのアーキテクチャを考えて実装すると思いますが、取り入れるアーキテクチャの一つにクリーンアーキテクチャがあります。 私自身もなんとか少しずつ考え方を取り入れようとしているのですが、UseCaseのInput Dataに関してはずっともやもやがあったので、「単に自分の理解が間違っているだけなのではないか？」「一回考え方を見直した方が良いのではないか？」という思いから今回見直してみることにしました。結果、見事にわかっていなかったようです。今でも理解しているかと言われると怪しいですが。。 参考文献は、クリーンアーキテクチャの原本である**Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Mar
主旨 Clean Architectureに登場するユースケースと外界とのアダプターとなるRepositoryとGatewayという概念について、実際に使う場面になった時にどちらをレイヤ名として使用するのが正しいのか？が気になったので、備忘録としてまとめておこうと思いました。 （個人的解釈なので、誤りがあればご指摘いただけると嬉しいです！） 結論 結局のところ、「ユースケースと外界とのアダプターとなる責務を果たしている」なら、どちらでも良さそうという結論に至りました（雑ですみません） そもそも気になった経緯 Clean Architectureといえば以下の図が有名かと思います。 緑色の部分にあるInterface AdapterにはGatewayと書かれていますが、実際に開発する時やWebでサンプルコードを見たりすると、Repositoryという命名で主にDBとの接続を責務とするレイヤが
ドメイン駆動設計やユースケース駆動開発などの文脈でレイヤードアーキテクチャやクリーンアーキテクチャといった言葉をよく聞くようになりました。 「名前は聞いたことあるけど、敷居が高そう......」「本は読んだけど実際に実装するイメージがつかない......」そんなことを感じている方もいらっしゃるのではないでしょうか？ 本トークではそんな方に向けて、簡単なアプリケーションの実装例とともに、クリーンアーキテクチャの考え方や実装する上での Laravel の機能についてお話します！ 2018/06/29 開催の PHP カンファレンス福岡2019 (https://phpcon.fukuoka.jp/2019/) の発表資料です。 Read less
ライブ放送のマイクが音ズレしていたので対処しました。 元動画: https://www.youtube.com/watch?v=5oJeSrwztPg JJUC CCC 2019 Spring の講演「「先行開発！クリーンアーキテクチャ -- ゼロから始める新規開発」の再演です。 講演の概要は下記URLのイベントページをご覧ください。 # URL イベントページ: https://nrs-seminar.connpass.com/event/174000/ Togetter: https://togetter.com/li/1502339 文字起こし（ログミーTechさま）: https://logmi.jp/tech/articles/323233 スライド: https://speakerdeck.com/nrslib/clean-architecture-with-java gi
クリーンアーキテクチャについて考察してみた
参考文献 先に本記事を書くにあたって参考にした文献を示す。 クリーンアーキテクチャ 翻訳 クリーンアーキテクチャ原文 クリーンアーキテクチャの目的 関心の分離 少なくとも以下のレイヤーが存在する。 ビジネスルールのレイヤー インターフェースのレイヤー _ クリーンアーキテクチャを適用した場合、以下のようなシステムを生み出す（らしい）。 フレームワークやライブラリ、モジュールに依存しない。つまりフレームワーク等の制約の影響を受けない 外部の要因を受けずにテストが可能 UIが独立しており、他の要因を受けずに変更が可能 データベースが独立しており、DBの種類によらず、ビジネスルールはDBの種類による影響を受けない ビジネスルールが外部の影響を受けない つまり外部のフレームワークやライブラリ、モジュールについてそれらがどのような設計になっているかなどを知らない状態 _ クリーンアーキテクチャを表現
GitHub - thanhchungbtc/vue-shopping-clean-architecture: Shopping cart app demonstrate clean architecture
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
2019/06/13追記 本記事の内容から考え方を改めました。 新しい考え方は【改訂版】クライアント、サーバー それぞれから視点で見た Clean Architecture にまとめましたので、こちらを見ていただければと思います。 一応、比較の意味を込めて本記事は残させていただきます。 TL;DR クライアントアプリ、サーバーアプリ両方を作ってみた上で、Clean Architecture とは何かを改めて考えて自分の中でまとめてみました。 登場するレイヤーや役割は、 こちら を参考にさせて頂きました。 なお、 View が、 ユーザーに対しての表示 の役割と、 ユーザーからの入力 の役割を兼ねているので、 入力側の役割を Action と別途名前を付けて分割させて頂きました。 Action View が、 ユーザーに対しての表示 の役割と、 ユーザーからの入力 の役割を兼ねているので、入
iOSやAndroid開発ではCleanArchitectureというアーキテクチャが利用されることがあるが、利用者によって解釈が大きく変わりそれが自分の中での混乱を招いているのでは？と考えた。なので自分なりに整理してみた。 CAとDDDの混乱 CleanArchitectureは ヘキサゴナルアーキテクチャ オニオンアーキテクチャ スクリーミングアーキテクチャ リーンアーキテクチャ UseCase駆動 などのアーキテクチャを参考にしており、オニオン型アーキテクチャは DDDのドメイン層からインフラ層への依存をなくすために依存性逆転の法則を用いて「ドメインが何にも依存しないように」する という目的で生まれたものなので、DDDの文脈を受け継いでいると考えてよいと思った。 Entity/UseCaseの混乱 クリーンアーキテクチャ(The Clean Architecture翻訳)を読み直して
CleanArchitectureについて自分なりに整理して実装してみた - Adwaysエンジニアブログ
はじめに こんにちは！MHWIにミラボレアスが来るのを楽しみにしているほんまです＠ｗ＠ アドウェイズのアドテクチームでは以前投稿したScalaでマイクロサービス化を進めるために考えたことで紹介したヘキサゴナルアーキテクチャの考えを取り入れたプロジェクトをベースに複数のサービスでScalaを使って開発を行って来ました。各サービスで独自の改善が行われていたりベースプロジェクトの設計思想と異なる実装がされていたりしたので改めてサンプルプロジェクトとドキュメントを作成したので記事にしたいと思います。 今回はヘキサゴナルアーキテクチャではなく、より実用的に内外の階層の分離され境界線を跨ぐデータの取扱いが明確に提案されているクリーンアーキテクチャの考えを参考にしました。 ベースプロジェクトの設計思想と異なる実装がされている課題についてはArchUnitというテスト用ライブラリを使ってテストでアーキテク
クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか - Runner in the High
何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの？」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている
各レイヤーは依存ルールをもたせます。 以下の図のとおり、円の内側のレイヤーにのみ依存することができ、より外側のレイヤーについては依存することができません。 つまり、外側のレイヤーで定義された関数、変数などは内側のレイヤでは扱うことができません。 メリット クリーンアーキテクチャを適用することにより、変更に強く、独立したテストが容易に実行できるようになります。 フレームワーク非依存：アーキテクチャは、機能満載のソフトウェアのライブラリに依存していない。これにより、システムをフレームワークの成約で縛るのではなく、フレームワークをツールとして利用できる。 テスト可能：ビジネスルールは、UI、データベース、ウェブサーバー、その他の外部要素がなくてもテストできる。 UI非依存：UIは、システムの他の部分を変更することなく、簡単に変更できる。たとえば、ビジネスルールを変更することなく、ウェブUIをコン
最近、 というか数年前から、AVPlayer(iOS)とかMediaPlayer(Android)とか、View層にあると情報の流れがごちゃっとして管理しづらいから、データレイヤーの方に無理矢理押し込んじゃった方がわかりやすいんじゃないか？とかぼんやり考えてました。それでちょっと仕事で音声プレイヤー周りを触る機会があったので、試しにClean ArchitectureのRepositoryに組み込んでみました。結構ちゃんと考えて作りました。Androidにも適用できると思っていて、軽く検証は済ませてます。まあ一旦鼻で笑っていただければ幸いです。 struct PlayerState PlayerからViewへの状態リレーを簡略化するため、Repositoryでstruct PlayerStateを生成して下流に流す形。 UserEventBinder ユーザーのタッチイベントをまとめたもの
ワタシ マク○ナル○ チョットデキル
つまりハンバーガーはclean architectureだったんだよ！ ΩΩΩ < ﾅ、ﾅﾝﾀﾞｯﾃｰ この記事で説明したいこと clean architectureを(実際の実装を含めて)マク○ナル○に例えて説明したいと思います！ なんでマク○ナル○？ 早い・安い・美味い、エンジニアの気絶のお供と言えばマク○ナル○だからです！（関係ない） キャッチーなタイトルだと書くモチベがあがりますよね! ファーストフードでは誰がオーダーを受けようが誰が料理しようが基本的に同じ味で提供されますね。 例えばキッチンのスタッフが入れ替わっても、レジの人は気にせずキッチンへのオーダーを通す事ができますが、これはclean architectureの疎結合に似ています。 またclean architecture(に限らない話ですが)はdbの依存関係を極力少なくしているのでdbの移行などでも最小限の工数で済む。
大岡由佳『りあクト! 第3.1版』BOOTHにて／紙本も販売中 on Twitter: "『Clean Architecture』に感じた違和感がこのレビューに言語化されてた。React と JSX を大前提とし Firestore が切り離せないコードを今書いてるけど、それを悪とする CA のほうが自分には前時代的に… https://t.co/pxZb0UttGg"
『Clean Architecture』に感じた違和感がこのレビューに言語化されてた。React と JSX を大前提とし Firestore が切り離せないコードを今書いてるけど、それを悪とする CA のほうが自分には前時代的に… https://t.co/pxZb0UttGg
目的 Interface Adapterのコード(Presenter、Repository、Gatewayなど)は、どのような役割を負うべきかを調べる。 動機 ローカルとサーバーのデータベース同期ライブラリを開発していて、「どのデータベースであろうとも、アプリケーションロジックを変更する必要はない」というデータベースの独立性を持ちたかったので、CleanArchitectureの導入を考えた。 そこでまだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて を参考にしながら進めていたのだが、Domain層の中にTranslatorが含まれているのに疑問を覚えた。 上の記事のサンプルコードを元に、データベースをRealmからCoreDataに取り替えた場合のことを考えてみたところ、ユースケースを書き換えなければいけないことに気がついた。 以下のコード
概要 Clean Architecture の構成に従ってクラスファイルを定義するツールです。 CLI で UseCase を Scaffolding することができます。 ‘Cl‘ean’Arc‘itecture から取り、ツール名称は ClArc としました。 クリーンアーキテクチャ関連記事 ◆クリーンアーキテクチャの概要 記事リンク: https://nrslib.com/clean-architecture/ ◆クリーンアーキテクチャの右下の図について 記事リンク: https://nrslib.com/clean-flow-of-control/ ◆ ClArc.CLI : CleanArchitecture のクラスを生成して登録まで行うツール（ｲﾏｺｺ） 記事リンク: https://nrslib.com/clarc-csharp/ github: https://githu
DDD関係なくても大丈夫ですよ！案1としては、1つのユースケースクラスからある程度責務を独立させられそうなオブジェクトを切り出します。 例えば、データAを取得する処理はDataAFetcher、変換する処理はDataAConverter…という風に(fetcherのネーミングは微妙な気もしますが一旦例として…) これはprivateメソッドで切り出すことは多いと思いますが、それをすると1クラスが多数のprivateメソッドで膨らんでしまいます。 そうではなくデータAを取得するという責務を持ったクラスして切り出してしまうことで、クラスの凝集度が上がり保守性が高まります。 特にテストはやりやすくなり、それらの独立したクラスそれぞれで単体テストを行い、ユースケースクラスはそれらを組み合わせる観点のテストだけ書けばよくなります。(余談ですが)テストのしやすさを追求することは、良い設計を追求すること
RestAPIをCleanArchitectureで実装する際のreq/resの持ち回りについて 概要 提題の通り、CleanArchitectureに則ってRestAPIを実装する場合に、 以下の2点に迷ったので、結論とそれに至るまでの考えを書き残しています。 requestオブジェクトはどのレイヤーまで持ち回すべきか？ responseオブジェクトはどのレイヤーで生成するべきか？ 背景 よくあるシンプルなCRUDアプリを実装する際、以下のような処理を実装するとします。 この場合、controller→usecase→repositoryとMVCやレイヤーアーキテクチャ的にパッケージを掘っていき処理を実現して行くのは誰もが違和感なく考えられることですが、 今回はCleanArchtectureを採用しているため、controller → usecase ← repositoryのような依
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Go + レイヤードアーキテクチャー】DDDを意識してWeb APIを実装してみる
リポジトリクラスのメソッド設計 - kawasima
Laravelとオブジェクト指向とクリーンアーキテクチャについて理解を深めてみた。 - Qiita
『SymfonyとDoctrineで簡単クリーンアーキテクチャ』をやってみる
Laravel - 『ドメイン駆動設計入門』してみて Clean な世界を垣間見た話し - Qiita
【Go言語】クリーンアーキテクチャで作るREST API – 株式会社ライトコード
自分が現状気に入っているアプリケーションのパッケージ構成をさらす - Qiita
Clean Architecture は飲んでも呑まれるな - Qiita
Clean Architecture for Unity
フロントエンドで 良いコードを書くために
クリーンアーキテクチャのUseCase Inputについて見直してみた
Clean ArchitectureにおけるRepositoryとGateway
Laravel でやってみるクリーンアーキテクチャ #phpconfuk
実践クリーンアーキテクチャ 音ズレ修正Ver.【プログラミング】
https://discourse.world/h/2017/08/11/Misconceptions-Clean-Architecture
クライアント、サーバー それぞれから視点で見た Clean Architecture - Qiita
CleanArchitectureへの自分の混乱を正す - Qiita
中継サービスにおけるGo言語でのクリーンアーキテクチャの実装例 - Qiita
音声/動画プレイヤーとClean Architecture雑メモ
CleanArchitectureにおけるInterface Adapterの役割を調べた - Qiita
ClArc.CLI – CleanArchitectureScaffolding
松岡@ログラス/DDD,アジャイルの質問箱です
RestAPIをCleanArchitectureで実装する際のreq/resの持ち回りについて