並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 13 件 / 13件

新着順 人気順

ビジネスロジックの検索結果1 - 13 件 / 13件

  • ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP

    Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識(ドメイン)を中心に据えたドメイン駆動設計に…

      ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP
    • 削除のビジネスロジックをドメイン層に閉じ込める簡単で強力な「DeletableIDパターンの紹介」

      この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか? 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか?は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか?」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。

        削除のビジネスロジックをドメイン層に閉じ込める簡単で強力な「DeletableIDパターンの紹介」
      • マイクロサービス化するならリビルドで!ビジネスロジックをGoで書き直してわかったこと - MonotaRO Tech Blog

        この記事では モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog のうち、主にアーキテクチャにおける詳細について紹介します。 自己紹介 マイクロサービス化について 課題を認識する スコープと技術選定 ゴールイメージを共有する 既存コードから分かった問題点 曖昧なデータ構造 処理フローの混在 アドホックなデータ取得 効果的な改善を行う 処理フローを分割する N+1問題とロジックの独立性を考慮した設計 安全に移行する 実行時のデータを取る 新旧比較による検証 まとめ 自己紹介 藤本 洋一 プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム 楽天、SaaSベンチャーを経て、モノタロウに入社してマイクロサービス化にとりくむエンジニアの話 2019年5月入社。商品検索基盤のマイクロサービスと

          マイクロサービス化するならリビルドで!ビジネスロジックをGoで書き直してわかったこと - MonotaRO Tech Blog
        • ビジネスロジックとは何か?

          業務システムの設計/開発/運用の文脈での、ビジネスロジックについて考察してみたいと思います。 ソフトウェア設計についての本やブログ記事などで、「ビジネスロジックは重要である」ということは、何度も何度も言われていて常識になっていて否定する人はほとんど居ないと思います。この点については文字通りの意味で納得するところなのですが、「ビジネスロジック」というのは、何なのでしょうか? 実際のところ ビジネスロジックとは何か?と問われて思いうかべる事は人によって異なるかもしれません。 要件定義書に書かれていることがビジネスロジック? 基本設計書に書かれていることがビジネスロジック? ○○テーブルの××カラムと□□テーブルの△△カラムを同一トランザクションで更新することがビジネスロジック? あるページの○○ボタンをクリックしたら、行を削除するということがビジネスロジック? どうも捉え所が無い感じです。 W

            ビジネスロジックとは何か?
          • 【Flutter解説】データをもとに画面処理を行う方法──ビジネスロジックと画面処理のアーキテクチャを知ろう

            サンプルアプリの概要 今回、使用するサンプルアプリは図1のようなアプリです。画面は3つありますが、すべて同じ画面であり、また、そのふるまいも同じです。 ただし、以下のように3つのアーキテクチャを使って実装します。それらの違いについて、アーキテクチャの構造とコード面から違いを見てほしいと思います。 図1:HTTPからJSONデータを取得し表示するサンプルアプリの画面 Stateのみを用いる方法 変更(イベント)通知(ProviderとChangeNotifier/Consumer)を用いる方法 BLoCパターン(ProviderとStreamController/StreamBuilder)を用いる方法 Stateのみを用いる方法 この方法はアーキテクチャと呼べるかわかりませんが、最も基本となる知識のみを使って実装する方法です。後で紹介する他の2つの方法と比べて、どこが変わるかを知っていただ

              【Flutter解説】データをもとに画面処理を行う方法──ビジネスロジックと画面処理のアーキテクチャを知ろう
            • ビジネスロジックとは? - Qiita

              エンジニアになるまでに想像していた何十倍もバグやエラーに遭遇します。最近聞いた言葉で一番印象だったのが、「ビジネスロジックエラー」についてまとめてみました。 そもそもビジネスロジックって何? ビジネスロジック(英:business logic)とは、業務システムの中で、具体的な業務で扱う様々な実体(商品、顧客、在庫など)を表現し、また、それらの関係や処理の方法、業務の流れなどをデータモデルやプログラムコードなどとして実装した部分(システムにおける、システム固有の処理を行う部分)のことを示します。 そのシステムとしての実際のお仕事をする部分が「ビジネスロジック」です。 ビジネスロジックの特徴として、現実の業務や事業におけるビジネスルールやワークフローが反映され、システムごとの固有性が高いことが挙げられます。 「ロジック」の意味は「プログラムにおける処理の内容、手順、方法」のことです。 プレゼ

                ビジネスロジックとは? - Qiita
              • 山口にあるSEO対策の会社「株式会社ビジネス・ロジック・ジャパン」 | SEO対策のセカンドオピニオン『集客パートナーNAGARE』

                SEOのセカンドオピニオン『集客パートナーNAGARE』は、下記のようなお困りごとのお手伝いをしています。 もっと売上を増やしたいのに横ばいが続き、行き詰まっている Googleのアップデートや競合の動きにより検索順位と売上が激減した SEOコンサル数社に相談して、コンサルも受けたけど売上につながらない 十分なアクセスとリード獲得はできている。けれど新規売上が増えない Web広告費を抑えるためにSEOを始めたけれど検索順位が上がらない SEO会社からコンサルを受けているけど売上が上がらず、信用もできなくなっている SEO集客したいけど何から始めたらいいか分からない 数十万かけてWebサイトを作ったのに「お問い合わせ」も「売上」もない 販路拡大や新規事業成功のためにSEO対策を丸投げできる会社を探している SEO対策を内製化したいので信頼できるSEO会社にコンサルを依頼したい など 御社がS

                  山口にあるSEO対策の会社「株式会社ビジネス・ロジック・ジャパン」 | SEO対策のセカンドオピニオン『集客パートナーNAGARE』
                • Railsでビジネスロジックをどこに置くのか問題

                  発端は Sustainable Web Development with Ruby on Railsの以下の文。(DeepLによる翻訳後) しかし、すべてのアプリの中で、Railsが明確な答え を持っていない部分が1つあります。それは、ビジネスロジックです。 ビジネスロジックとは、アプリのコアロジックを指す用語で、アプ リが必要とする処理に特化したものを指します。例えば、誰かが製品 を購入するたびにメールを送信する必要がある場合、その製品がバー モント州に配送される場合のみメールを送信し、カンザス州に配送され る場合はテキストメッセージを送信します。これはビジネスロジック です。 Railsの開発者がよく抱く最大の疑問は、「この種のロジックのコードは どこに行くのか」ということです。Railsには明確な答えがありません。 ビジネスロジックをActive Recordsに置かないことです。そ

                    Railsでビジネスロジックをどこに置くのか問題
                  • 「ビジネスロジック」とは何か、どう実装するのか - Qiita

                    アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い

                      「ビジネスロジック」とは何か、どう実装するのか - Qiita
                    • 「Controller にビジネスロジックを書くな」の対応パターン - Qiita

                      はじめに 「Controller にビジネスロジックを書くな」と言われることがしばしばあると思います。 この記事では、そもそもそれは何がいけないのか、どうすればいいのかを整理しました。 具体的なコードまでは書いていないですが、各ケースを図で表現して、できるだけ分かりやすいようにまとめました。 「Controller に全部書く」とはどんな状態か 「Controller にビジネスロジックを書くな」の対応の前に、「Controller に全部書く」という状態について整理しようと思います。 この記事で言う「Controller に全部書く」状態とは、MVC を使っていて、Model クラスがデータの入れ物 (多くの場合、DB スキーマとほぼ一致) で、Service クラスが存在せず、プログラムの処理が全て Controller に書かれている状態です。 イメージとしては、以下の図のような状態

                        「Controller にビジネスロジックを書くな」の対応パターン - Qiita
                      • 『削除のビジネスロジックをドメイン層に閉じ込める簡単で強力な「DeletableIDパターンの紹介」』へのコメント

                        前提となっているTodo::<メソッド> → Todoの次のstateという書き方が興味深い。これ自体もパターン名あるのかな。そうなると、deleteも同じ形にしてなんらかのStateを返すのは自然ではある。(メソッド名はちょい不自然)

                          『削除のビジネスロジックをドメイン層に閉じ込める簡単で強力な「DeletableIDパターンの紹介」』へのコメント
                        • OpenAI API の Function calling で関数を複数同時に呼び出し、ビジネスロジックを精一杯APIに寄せてみた - Kaizen Platform 開発者ブログ

                          こんにちは、AI活用研究チームのYuです。 先日リリースされた Open API の Function calling で、複数関数の同時実行を実験してみた内容を記載します。 Function calling とは Function calling は、 関数定義をしておくとその条件に基づいてJSON で関数および変数を返してくれるものです。 Function calling and other API updates 使い方の解説はこちらのブログが詳しいです。 [OpenAI] Function callingで遊んでみたら本質が見えてきたのでまとめてみた | DevelopersIO 複数関数の同時実行 今回の実験に至ったのは、Twitterで以下の投稿を見かけたことが発端です。 工夫することで同時に2個以上のタスクの関数呼び出し(Function Calling)を実行することができ

                            OpenAI API の Function calling で関数を複数同時に呼び出し、ビジネスロジックを精一杯APIに寄せてみた - Kaizen Platform 開発者ブログ
                          • ドメイン駆動設計(DDD)についてとビジネスロジックの別け方

                            ドメイン駆動設計(DDD)とは 顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法のこと。 つまりは、業務担当者であるドメインエキスパートと開発者が、チームの共通言語である「ユビキタス言語」を用いて「ドメインモデル」を構築し、それをコードとして実装する。 また大規模で密結合なシステムにならないようにドメイン(問題領域)と境界づけられたコンテキストにてシステムを分割し、コアドメインという最重要領域、つまりは最も大事な業務領域に集中して開発を行う。 ドメインイベントの実装方法 - 1.概要編 アーキテクチャ ドメイン駆動設計の戦術的設計には、主に以下の4種類のアーキテクチャがあります。 レイヤーアーキテクチャ ヘキサゴナルアーキテクチャ クリーンアーキテクチャ イベント駆動アーキテクチャ 今回はレイヤーアーキテクチャを用いて実装方法を説明していきます。 プレゼン

                              ドメイン駆動設計(DDD)についてとビジネスロジックの別け方
                            1