タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
クリーンアーキテクチャの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では同様の質問がかなり盛り上がっている
はじめに Clean Architectureやレイヤードアーキテクチャでは、どのようにレイヤーを定義するかついては言及されています。 そのような中usecase(レイヤードアーキテクチャではApplication層)をどのように実装するべきかについての議論は少ないです。 しかし私はリーダブルなアーキテクチャを実現するために、一番大切なことはusecaseを適切に実装することであると考えています。 そこでusecaseを実装する上で起こりがちな抽象度の問題を例に、リーダブルなアーキテクチャを考えいていきたいと思います。 サンプル 1:1のチャットアプリでUserとWorkerが存在して会話ができるアプリを例にあげます。 以下の図では青い背景はinfraの関数実行、緑色の背景はdomainの関数実行、赤い背景はusecaseの関数実行を示しています。 usecaseのCreateChat関数
「Android Meetup」は、to C向けサービスを提供するGMOペパボ株式会社、株式会社ZOZOテクノロジーズ、株式会社サイバーエージェンがAndroid開発事情や、直近の取り組みについて発表をするイベントです。GMOペパボ株式会社の伊藤氏は、「minne byGMOペパボ」アプリケーション開発におけるアーキテクチャ選定について発表しました。 ハンドメイドマーケット「minne」アプリを担当 伊藤拓海氏（以下、伊藤）：「中～大規模アプリのminneはどうアーキテクチャを選定したか」ということで、GMOペパボの伊藤が発表したいと思います。よろしくお願いします。 まず軽く自己紹介します。伊藤といいます。よろしくお願いします。GMOペパボではパートナー（GMOインターネットグループに置ける従業員の呼称）同士をあだ名で呼び合う風習があります。僕は名前が拓海なので「tick-taku」と呼ば
クリーンアーキテクチャの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では同様の質問がかなり盛り上がっている
PostgreSQL🐘と 比較しながら選ぶデータベース / select-database-usecase
Open Source Conference 2020 Online/Niigataの登壇資料です。 https://ospn.connpass.com/event/181888/
この記事はSwift 5.7以前に書かれたものです。そのため下記のprotocolは型消去せずとも実装可能となっています。 最初にこの文章の結論 この文章は、ロジックを処理する次のような型をアプリケーションの中で定義してみたらどうかな、と考えているのを文章にしてみたものです。 protocol UseCase { associatedtype Parameters associatedtype Success func execute( _ parameters: Parameters, completion: ((Result<Success, Error>) -> ())? ) func cancel() } なぜこんな事を考えているかというと、iOS VIPERアーキテクチャ研究読本（仮）という電子書籍を作ってみたいなと考えていて、まずはサンプルコードを作ろうとしているためです。 V
Controller, UseCase, Service (および Model) の役割分担についての考察 - Qiita
この記事について Laravel Advent Calendar 2020 の21日目の記事です。 以前以下の記事を書いてから、とあるプロジェクトで導入し、そこそこ上手く機能している実感を得たんですが、新しく加わったメンバーに意図をうまく伝えるのが難しかったり、既存のメンバーでも（自分も含めて）役割分担に迷いが生じることがときどきあるので、表題に挙げた4つのクラス分類について、どのように役割分担していくといいか、指針を明確化しておこうという試みです。 Laravel で Request, UseCase, Resource を使いコントロールフローをシンプルにする - Qiita 筆者独自の基準も含まれているため、既存の書籍や資料などと異なる定義や使い方があるかもしれませんのでご了承ください。 また、本記事はほとんど Laravel と関係ありませんが、上記の記事の続きということで Lar
UseCaseの凝集度を高める Goのpackage戦略 / Go packaging strategy to increase use case cohesion
UseCaseの凝集度を高める Goのpackage戦略 / Go packaging strategy to increase use case cohesion
前提例によって Clean Architecture のあの図より。 Clean Coder Blog Clean Architecture 自体はいろいろ誤解しやすかったりするが、他の類似のパターンも言ってることはそんなに大きく違いはないのでそのまま参照する。 まず、基本的なことを確認しておくと、 いわゆるフレームワークでコードの起点になる部分はロジックを書く場所ではない という点がある。 例えば Rails MVC は ( routing を除けば ) Controller が起点になるが、Controller は Usecase の外側に位置しているReact 的な View Framework は Presenter 辺り以上のように、メジャーなフレームワークのコードの起点となるパーツは、基本的にロジックを書く場所として機能するはずの Usecase や Entity ではない。そ
*Qiitaに掲載していたものと同じ内容をこちらに移転しました（作者は同じです）。 今回のサンプルコードはyu-croco/ddd_on_scalaに掲載していますので、気になる方は覗いてみてください。 経緯 Scala(PlayFramework) x DDDでアプリケーションを実装する際、UseCase層（Application層）を実装する際に辛さが出てくる。 何が辛いかと言うと、型のネストである。 というのも、 UseCase層ではエンティティ操作の過程で仕様周りのバリデーションをやることになりEitherが出てくる 例：ハンターがモンスターから素材を剥ぎ取るためには、モンスターが既に死んでいる必要がある (PlayFrameworkだと特に)Repository層での呼び出してFutureが出てくる そのため、UseCase層での各処理の型合わせが必然的に複雑になる傾向にある。
複数のCloud Functions entrypointsを1 GitHub repository(NodeJS with TypeScript)で管理する <usecaseを添えて>
この記事はGoogle Cloud Japan Customer Engineer Advent Calendar 2019, 4日目の記事です。 TL;DR皆様こんにちは、Google Cloud Customer EngineerのArashiと申します。 このエントリーでは、同一の機能要件内でCloud Functionsを分けたい時、どのように1 GitHub repositoryでコードを管理するかを実際のユースケースをまじえて紹介していきます。 今すぐ完成品を!という方はこちら https://github.com/jupemara/gcp-advent-calendar-2019-001。 ※usecaseとユースケースという表記が出てきますが、usecaseはオニオンアーキテクチャで言うところのapplication service, クリーンアーキテクチャで言うところのu
ターゲット クリーンアーキテクチャ 初級者~中級者 概要 WebAPI開発時はバックエンドのアーキテクチャを考えて実装すると思いますが、取り入れるアーキテクチャの一つにクリーンアーキテクチャがあります。 私自身もなんとか少しずつ考え方を取り入れようとしているのですが、UseCaseのInput Dataに関してはずっともやもやがあったので、「単に自分の理解が間違っているだけなのではないか？」「一回考え方を見直した方が良いのではないか？」という思いから今回見直してみることにしました。結果、見事にわかっていなかったようです。今でも理解しているかと言われると怪しいですが。。 参考文献は、クリーンアーキテクチャの原本である**Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Mar
Usecase使う？使わない？ - Qiita
まずはじめに この記事では、私が、ユースケース(Usecase)を 「使った方が良さそう」や「使わなくても良さそう」 を判断するときのポイントを書かせていただこうと思います。 当たり前だろ！と思うことかもしれませんが、 現場で「どういう時に使い分けてますか？」と聞かれることが多々あるので、 今回その内容をアウトプットできたらなと思います。 (ユースケースを "使う" という表現が正しいかは怪しいですが、文脈で汲み取っていただけると嬉しいです） Usecaseとは まず、ユースケースの基本的な定義から説明します。 chat-GPT先生に聞いてみた結果がこちら ユースケースは、ビジネス要件やシステムの機能を実現するためのシナリオや振る舞いを表現する概念であり、 システムのユーザー（エンドユーザーや他のシステム）が実現したい目標や操作を捉えます。 ただし、ユースケースを必ずしも作成する必要はあり
経緯 Scala(PlayFramework) x DDDでアプリケーションを実装する際、UseCase層（Application層）を実装する際に辛さが出てくる。 何が辛いかと言うと、型のネストである。 というのも、 UseCase層ではエンティティ操作の過程で仕様周りのバリデーションをやることになりEitherが出てくる 例：ハンターがモンスターから素材を剥ぎ取るためには、モンスターが既に死んでいる必要がある (PlayFrameworkだと特に)Repository層での呼び出してFutureが出てくる そのため、UseCase層での各処理の型合わせが必然的に複雑になる傾向にある。 サンプル 例として、なんちゃってモンハンを想定して「ハンターがモンスターにダメージを与える」というユースケースを実装してみる。 *いろんな突っ込みがあると思うのですが、マサカリはヤメてください。 forの
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リーダブルアーキテクチャ - usecaseにおける時間軸と抽象度の統一 - Qiita
「minne」はなぜ「MVVM＋UseCase＋Repository」なのか 3つのアーキテクチャを選んだ5つの理由
Swiftでビジネスロジックを実行するUseCaseのprotocolを作りたい話 2019 - Qiita
Usecaseを使おう（コードのentry pointからロジックを分離する方法の例）
ScalaのEffを使ってDDDのUseCase層をいい感じに書いてみる
クリーンアーキテクチャのUseCase Inputについて見直してみた
ScalaのEffを使ってDDDのUseCase層をいい感じに書いてみる - Qiita
music.tower.jp
upnow.jp
www.asahi.com
haogadget.com
www.j-cast.com
ja.wikipedia.org