並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 14 件 / 14件

新着順 人気順

UseCaseの検索結果1 - 14 件 / 14件

タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。

UseCaseに関するエントリは14件あります。 資料障害対応開発 などが関連タグです。 人気エントリには 『「minne」はなぜ「MVVM+UseCase+Repository」なのか 3つのアーキテクチャを選んだ5つの理由』などがあります。
  • 「minne」はなぜ「MVVM+UseCase+Repository」なのか 3つのアーキテクチャを選んだ5つの理由

    「Android Meetup」は、to C向けサービスを提供するGMOペパボ株式会社、株式会社ZOZOテクノロジーズ、株式会社サイバーエージェンがAndroid開発事情や、直近の取り組みについて発表をするイベントです。GMOペパボ株式会社の伊藤氏は、「minne byGMOペパボ」アプリケーション開発におけるアーキテクチャ選定について発表しました。 ハンドメイドマーケット「minne」アプリを担当 伊藤拓海氏(以下、伊藤):「中~大規模アプリのminneはどうアーキテクチャを選定したか」ということで、GMOペパボの伊藤が発表したいと思います。よろしくお願いします。 まず軽く自己紹介します。伊藤といいます。よろしくお願いします。GMOペパボではパートナー(GMOインターネットグループに置ける従業員の呼称)同士をあだ名で呼び合う風習があります。僕は名前が拓海なので「tick-taku」と呼ば

      「minne」はなぜ「MVVM+UseCase+Repository」なのか 3つのアーキテクチャを選んだ5つの理由
    • エンタープライズ企業の障害対応革新 – PagerDuty導入とその成果/pagerduty-usecase-of-aeon

      PagerDuty on Tour TOKYO 2024での発表資料です。 https://www.pagerduty.co.jp/pagerdutyontourtokyo/

        エンタープライズ企業の障害対応革新 – PagerDuty導入とその成果/pagerduty-usecase-of-aeon
      • クリーンアーキテクチャの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では同様の質問がかなり盛り上がっている

          クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか - Runner in the High
        • PostgreSQL🐘と 比較しながら選ぶデータベース / select-database-usecase

          Open Source Conference 2020 Online/Niigataの登壇資料です。 https://ospn.connpass.com/event/181888/

            PostgreSQL🐘と 比較しながら選ぶデータベース / select-database-usecase
          • UseCaseの凝集度を高める Goのpackage戦略 / Go packaging strategy to increase use case cohesion

            UseCaseの凝集度を高める Goのpackage戦略 / Go packaging strategy to increase use case cohesion

              UseCaseの凝集度を高める Goのpackage戦略 / Go packaging strategy to increase use case cohesion
            • Controller, UseCase, Service (および Model) の役割分担についての考察 - Qiita

              この記事について Laravel Advent Calendar 2020 の21日目の記事です。 以前以下の記事を書いてから、とあるプロジェクトで導入し、そこそこ上手く機能している実感を得たんですが、新しく加わったメンバーに意図をうまく伝えるのが難しかったり、既存のメンバーでも(自分も含めて)役割分担に迷いが生じることがときどきあるので、表題に挙げた4つのクラス分類について、どのように役割分担していくといいか、指針を明確化しておこうという試みです。 Laravel で Request, UseCase, Resource を使いコントロールフローをシンプルにする - Qiita 筆者独自の基準も含まれているため、既存の書籍や資料などと異なる定義や使い方があるかもしれませんのでご了承ください。 また、本記事はほとんど Laravel と関係ありませんが、上記の記事の続きということで Lar

                Controller, UseCase, Service (および Model) の役割分担についての考察 - Qiita
              • IoT USECASE-事例でわかるビジネスに役立つIoT

                IoT事例 - ビジネスの最前線 ビジネスのデジタル化には通信でつなぐIoTが欠かせません。センサーやカメラなどのモノを遠隔で管理し、取得したデータの分析やAI活用で実現した業務効率化や新規事業の最新事例を紹介しています。 IoT事例 - ビジネスの最前線 ビジネスのデジタル化には通信でつなぐIoTが欠かせません。センサーやカメラなどのモノを遠隔で管理し、取得したデータの分析やAI活用で実現した業務効率化や新規事業の最新事例を紹介しています。 IoT事例 - ビジネスの最前線 ビジネスのデジタル化には通信でつなぐIoTが欠かせません。センサーやカメラなどのモノを遠隔で管理し、取得したデータの分析やAI活用で実現した業務効率化や新規事業の最新事例を紹介しています。

                  IoT USECASE-事例でわかるビジネスに役立つIoT
                • Usecaseを使おう(コードのentry pointからロジックを分離する方法の例)

                  前提例によって Clean Architecture のあの図より。 Clean Coder Blog Clean Architecture 自体はいろいろ誤解しやすかったりするが、他の類似のパターンも言ってることはそんなに大きく違いはないのでそのまま参照する。 まず、基本的なことを確認しておくと、 いわゆるフレームワークでコードの起点になる部分はロジックを書く場所ではない という点がある。 例えば Rails MVC は ( routing を除けば ) Controller が起点になるが、Controller は Usecase の外側に位置しているReact 的な View Framework は Presenter 辺り以上のように、メジャーなフレームワークのコードの起点となるパーツは、基本的にロジックを書く場所として機能するはずの Usecase や Entity ではない。そ

                  • ScalaのEffを使ってDDDのUseCase層をいい感じに書いてみる

                    *Qiitaに掲載していたものと同じ内容をこちらに移転しました(作者は同じです)。 今回のサンプルコードはyu-croco/ddd_on_scalaに掲載していますので、気になる方は覗いてみてください。 経緯 Scala(PlayFramework) x DDDでアプリケーションを実装する際、UseCase層(Application層)を実装する際に辛さが出てくる。 何が辛いかと言うと、型のネストである。 というのも、 UseCase層ではエンティティ操作の過程で仕様周りのバリデーションをやることになりEitherが出てくる 例:ハンターがモンスターから素材を剥ぎ取るためには、モンスターが既に死んでいる必要がある (PlayFrameworkだと特に)Repository層での呼び出してFutureが出てくる そのため、UseCase層での各処理の型合わせが必然的に複雑になる傾向にある。

                      ScalaのEffを使ってDDDのUseCase層をいい感じに書いてみる
                    • gomock とgotests を使ったCleanArchitectureのusecaseテスト生成術 - Qiita

                      前提 CleanArchitecture を採用する CleanArchitecture のusecase 層のテストをする repository 層はgomockによってモックが生成されている テストの雛形はVSCode の拡張のgotests の形に基づく参考: VS CodeのGo言語テストコード生成ツールを使ってみたらめちゃくちゃ便利だった話とか 概要 要件としてrepository 層の関数をモックとして扱う必要がある。 gotests で雛形を生成してgomock を用いつつ引数としてmockの初期化関数を渡してモックパターンを柔軟に設定する 参考にも記載したのですが上記サイトがgomock を使う上で大変参考になりました。思想はこの記事から引き継いでいます。 例:テストしたい関数 type UserUsecase interface { Get(ctx context.Con

                        gomock とgotests を使ったCleanArchitectureのusecaseテスト生成術 - Qiita
                      • ScalaのEffを使ってDDDのUseCase層をいい感じに書いてみる - Qiita

                        経緯 Scala(PlayFramework) x DDDでアプリケーションを実装する際、UseCase層(Application層)を実装する際に辛さが出てくる。 何が辛いかと言うと、型のネストである。 というのも、 UseCase層ではエンティティ操作の過程で仕様周りのバリデーションをやることになりEitherが出てくる 例:ハンターがモンスターから素材を剥ぎ取るためには、モンスターが既に死んでいる必要がある (PlayFrameworkだと特に)Repository層での呼び出してFutureが出てくる そのため、UseCase層での各処理の型合わせが必然的に複雑になる傾向にある。 サンプル 例として、なんちゃってモンハンを想定して「ハンターがモンスターにダメージを与える」というユースケースを実装してみる。 *いろんな突っ込みがあると思うのですが、マサカリはヤメてください。 forの

                          ScalaのEffを使ってDDDのUseCase層をいい感じに書いてみる - Qiita
                        • UseCaseクラスを使って FatControllerやFatModelにしない

                          Railsアプリ開発で陥りがちなFatController/FatModel問題を、可読性低下・保守性悪化・コード重複助長という視点から整理し、その根本原因となる「関心事の分離不足」を解説します。Rails勉強会 (1) UseCaseクラスを導入することで、Controllerはリクエスト受け取りと…

                            UseCaseクラスを使って FatControllerやFatModelにしない
                          • クリーンアーキテクチャのUseCase Inputについて見直してみた

                            ターゲット クリーンアーキテクチャ 初級者~中級者 概要 WebAPI開発時はバックエンドのアーキテクチャを考えて実装すると思いますが、取り入れるアーキテクチャの一つにクリーンアーキテクチャがあります。 私自身もなんとか少しずつ考え方を取り入れようとしているのですが、UseCaseのInput Dataに関してはずっともやもやがあったので、「単に自分の理解が間違っているだけなのではないか?」「一回考え方を見直した方が良いのではないか?」という思いから今回見直してみることにしました。結果、見事にわかっていなかったようです。今でも理解しているかと言われると怪しいですが。。 参考文献は、クリーンアーキテクチャの原本である**Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Mar

                              クリーンアーキテクチャのUseCase Inputについて見直してみた
                            • Usecase使う?使わない? - Qiita

                              まずはじめに この記事では、私が、ユースケース(Usecase)を 「使った方が良さそう」や「使わなくても良さそう」 を判断するときのポイントを書かせていただこうと思います。 当たり前だろ!と思うことかもしれませんが、 現場で「どういう時に使い分けてますか?」と聞かれることが多々あるので、 今回その内容をアウトプットできたらなと思います。 (ユースケースを "使う" という表現が正しいかは怪しいですが、文脈で汲み取っていただけると嬉しいです) Usecaseとは まず、ユースケースの基本的な定義から説明します。 chat-GPT先生に聞いてみた結果がこちら ユースケースは、ビジネス要件やシステムの機能を実現するためのシナリオや振る舞いを表現する概念であり、 システムのユーザー(エンドユーザーや他のシステム)が実現したい目標や操作を捉えます。 ただし、ユースケースを必ずしも作成する必要はあり

                                Usecase使う?使わない? - Qiita
                              1

                              新着記事