アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い
ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP
Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に…
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか？ 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか？は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか？」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。次に、ビジネスロジックの実装方法について紹介します。前回はこちらから。 ビジネスロジックの実装の2つのパターン 大嶋勇樹氏：ここまでの流れは、「そもそも3層アーキテクチャって何だっけ？」というところから、特に「真ん中のビジネスロジックって何だっけ？」と（いう話）、「例えば、このあたりがビジネスロジックだよね」と（いう話）。（そして）「ビジネスロジックの中には、ドメインロジックとユースケースの2種類があると考えるとわかりやすいですよ」というところまで話してきました。 ドメインロジックは、システム都合ではないコアなルールみたいなもので、ユースケースは処理の流れを実現することです。これを踏まえて
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。ここからは、3層アーキテクチャの典型例について話し、ビジネスロジック層について深掘りして紹介します。前回はこちらから。 3層アーキテクチャ+MVCの通信の流れ 大嶋勇樹氏：こうやって話してくると、具体的に「じゃあコードをどういうふうに書くの？」「どういうクラスで書くの？」ということを疑問に思うかもしれません。派生形やちょっと違う例もいろいろありますが、典型的な例を1個書いています。 （スライドを示して）これが3層アーキテクチャとMVC（Model、View、Controller）ともいえる典型例です。クラス名のつけ方はいろいろあります。これはどういう構造になっているかというと、まずCont
Android SDKでビジネスロジックのテストを自動化するには：Androidアプリ開発テスト入門（2）（1/3 ページ） ビジネスロジックのテスト自動化から始めよう 本連載ではAndroidアプリを開発している方のためにテストの基本的なノウハウを解説しています。前回の「Androidアプリ開発でテストを始めるための基礎知識」では、Androidアプリ開発におけるテストの課題を解説し、EclipseとJUnitを使った単体テストのやり方を環境構築やコードの書き方を含め紹介しました。今回は「ビジネスロジック」のテストについて説明していきます。一口にビジネスロジックといっても読者の皆さんが持つ定義は、さまざまかと思います。 Android開発におけるビジネスロジックとは 本連載ではビジネスロジックを「Androidのシステムに依存しない独立した処理」と定義します。具体的には文字列処理や日付・
無限のメモリ空間と絶対に落ちないプロセスを仮定して「ビジネスロジック」をあぶり出す - assertInstanceOf('Engineer', $a_suenami)
先日、前職の上司から「そろそろプロフィールに"詩人"を追加するべきだ」と言われました a-suenami です。今日も今日とて詩人業を行なっていきますよ！ 「ビジネスロジック」とは何か 最近、業務で、比較的中長期的なアーキテクチャの見直しだったり、新機能の設計だったりをさせてもらう機会が増えた。 コンポーネントをどういう風に分割するかとか、それぞれのコンポーネントを主にどのチームでメンテナンスしていくかとか、そういうのを考えるのは楽しい反面、かなり熟慮に熟慮を重ねないといけないものでもあるのでかなり責任を感じるというのもある。 まあ、そんなこんなでいろいろうーんうーんって悩んでいると昔（たぶん DDD コミュニティだと思うけど）誰かに言われた「無限のメモリ空間と絶対に落ちないプロセスがあったとして、それでもそのコードを書かないといけないのならそれがあなたのドメインだ」という言葉だ。 モデリ
2019年のwebAPIの設計を取り巻く問題と技術シリーズ そのに 「ビジネスロジック」は誰が持つべき？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
前回の記事の続きです。 前回は、「時代が変わるとサーバーアプリケーションの役割も変わるよね。そうすると必要な要素技術も変わっていくよね」という話でした。今回は、じゃあ「サーバーアプリケーションがJSON喋るマンになって、クライアントアプリケーションとの協働でユーザー体験が実現されるようになってきた今、"ビジネスロジック"はだれが持つべきなの？」って話をしたいと思います。 基本的にはサーバーでもってあげたほうが楽 さて、サーバーサイドでなんでもやる牧歌的な時代は過ぎ去り、クライアントサイドとサーバーサイドがコラボレーションしてひとつの体験を提供するようになった昨今、「そのアプリケーションの体験を成り立たせるための"ロジック"をどっちに書くのか」という問題が立ち上がってきます。わたしの私見ですが、これはなるべくならサーバーサイドで請け負ってあげるのがよいのではないでしょうか。その理由は、クライ
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。続いて、3層アーキテクチャそれぞれの役割について紹介します。前回はこちらから。 本セッションにおける「3層アーキテクチャ」の定義 大嶋勇樹氏：ということで、ここまでで「そもそもアプリケーションアーキテクチャとは何でしょう」という話をしました。ここからが本題的なところで、まず最も基本、最も基本というのは僕の意見ですが、3層アーキテクチャについて話していこうと思います。なにか気になる点があれば、Q&Aに気軽に（質問して）もらえればそちらも回答します。 では、3層アーキテクチャについてに入っていこうと思います。3層アーキテクチャと言われた時に想像するものは、少なくとも私の場合は2つあります。 （
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。さらに、ビジネスロジック層の役割について深掘りします。前回はこちらから。 リクエストの形式チェックはビジネスロジック層の役割か？ 大嶋勇樹氏：（スライドを示して）続けて「これはビジネスロジック？」（というもの）をもう少し見ていこうと思います。2つ目として、リクエストの形式チェックがあります。 例えば、リクエストの必須パラメーターが足りているかとか、データサイズは決められた範囲内かとか、そういうチェックがあると思いますが、個人的にこれはプレゼンテーション層でチェックすべきものだと思っています。 なぜかというと、リクエストは利用者とのインターフェイス、利用者との境界での約束事に対するチェックな
redux domain ビジネスロジック
マイクロサービス化するならリビルドで！ビジネスロジックをGoで書き直してわかったこと - MonotaRO Tech Blog
この記事では モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog のうち、主にアーキテクチャにおける詳細について紹介します。 自己紹介 マイクロサービス化について 課題を認識する スコープと技術選定 ゴールイメージを共有する 既存コードから分かった問題点 曖昧なデータ構造 処理フローの混在 アドホックなデータ取得 効果的な改善を行う 処理フローを分割する N+1問題とロジックの独立性を考慮した設計 安全に移行する 実行時のデータを取る 新旧比較による検証 まとめ 自己紹介 藤本 洋一 プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム 楽天、SaaSベンチャーを経て、モノタロウに入社してマイクロサービス化にとりくむエンジニアの話 2019年5月入社。商品検索基盤のマイクロサービスと
CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
ビジネスロジック - Wikipedia
ビジネスロジック（英: business logic）は、データベース上のデータに対する処理手順といったようなものを指す、ソフトウェア工学的な用語である。「アルゴリズム」という語が説明に使われていることがあるが、アルゴリズムは数学的・論理的に明確な概念であり間違った説明の仕方である。基本的には、エンタープライズ系（業務支援系）ソフトウェアを開発する企業が内部的に、もしくは顧客への販売促進のために用いる用語である。この用語は、主にプログラムが3層構造となるWebアプリケーション開発で使われる。ビジネスロジックは3層の中の中間層（アプリケーションサーバ）に相当する。いずれにしても、ビジネスロジックという用語は明確な定義がなく、人によって意味が異なる可能性がある。 ビジネスロジックの範囲[編集] 実世界のビジネスオブジェクト（勘定、貸付金、旅程表、在庫目録などなど）をモデル化したもの そのような
最近、ビジネスロジックがふんだんに盛り込まれた業務システムというのはあまりありません。 「データの出し入れ」が基本ということは、データの格納庫が必要になってくるわけで、それがデータベースになります。最近ではオブジェクト指向データベースも使われ始めましたが、まだまだリレーショナルデータベースの方がよく使われています。 オブジェクト指向で開発していると、ほとんど必ず問題となるのが、リレーショナルデータベースとオブジェクト指向のインピーダンスミスマッチです。データベースは「データ」を扱い、オブジェクト指向は「振る舞い」を扱います。つまり、「振る舞い」をいかにして「データ」に落とすかというのが、問題となるわけです。 最近では、「DAO(Data Access Object」パターンや「O/Rマッピング」というものを使い、オブジェクト指向とリレーショナルデータベースの差を埋める努力がされています。D
ビジネスロジックとは
Landscape トップページ | < 前の日 2005-12-11 2005-12-12 次の日 2005-12-13 > Landscape - エンジニアのメモ 2005-12-12 ビジネスロジックとは 当サイト内を Google 検索できます * ビジネスロジックとはこの記事の直リンクURL: Permlink | この記事が属するカテゴリ: [プログラミング] 私はビジネスロジックを「アプリケーションがおこなう処理やルール、その手順」という意味で使っている。 ビジネスロジックという言葉を使うようになったのは、いつからだろう。私の周りで会話で普通に使われるようになったのは、3年から4年前くらいだろうか。書籍やウェブではもっと前から当たり前に使われてたんだろうけどね。 コンピュータ系の用語は、使う人によって意味が異なったり別の物を指していることがよくある。私の中の「ビジネスロジッ
この記事は Pixta アドベントカレンダー 2017 の 7日目の記事です。 こんにちは、昨年末に株式会社ピクスタに入社したエンジニアの大村です。てくすたに書くのは2回目になります。前回はペアプロについての記事でした。 当時は PIXTA のチームにいたのですが、現在は fotowa の開発チームに移って奮闘中です。 今回は、その fotowa チームでの開発プロセス改善の一環で行った、ガイドラインの策定について紹介しようと思います。 fotowa とは 気軽にプロのカメラマンを予約して、ハイクオリティな写真を撮影できるサービスです。サービスのピークは11月の七五三です。撮影事例はこちらをご参照ください。 fotowa の開発チーム体制は 2016年2月にサービスイン(開発は2015年から)して以来、順調に事業とシステムを拡大しています。 そんな中、初期から開発を引っ張ってきた id:n
データベース基礎、モデルとビジネスロジックの関係 ーー「非エンジニアの起業家が知っておくべきプログラミングの知識 #09」 - BRIDGE（ブリッジ）テクノロジー＆スタートアップ情報
編集部注：本稿は初心者向けにプログラミングやWebデザインの講座を開催している TechAcademy（テックアカデミー）による連載企画。「非エンジニアの起業家が知っておくべきプログラミングの知識」というテーマで数回に分けて極めて基礎的なプログラミングの基礎知識をお伝えする。全連載はこちらから photo credit: tec_estromberg via photopin cc 「非エンジニアが知っておくべきプログラミングの知識」というテーマで、10回に分けてお届けする連載企画。第9回目のテーマは「データベースの基礎」です。 前回は「これから始めるRubyのエッセンス」というテーマでお送りしました。今回は、PHPやRubyなどサーバーサイドで動作するプログラミング言語と合わせて、ユーザーの登録情報といったWebサービスを構築する上で必要不可欠な「データベース」の考え方についてご紹介しま
【Laravel】「『Controllerに入る』と思ったならッ！ その時スデに（ほぼ）ビジネスロジックは終わっているんだッ！」という、DIコンテナのお話 - Qiita
【Laravel】「『Controllerに入る』と思ったならッ！ その時スデに（ほぼ）ビジネスロジックは終わっているんだッ！」という、DIコンテナのお話PHPLaravelDDDDICreanArchitecture 発端 QiitadonでDIの話題が盛り上がっていた時に「LaravelのDIはつよい」みたいなことを書いたら一部反響があったので、その解説です。 はじめに LaravelのDIコンテナ（サービスコンテナ）はめちゃ強力です。「DIコンテナとは何ぞや」という説明は良記事が大量に存在するので詳細を省きますが、超初心者向けに端折った説明をすると「クラスをnewするときに必要なインスタンスを外からブチ込んでくれる人1」みたいな感じです。 実際にコイツのヤバさをサンプルコードで確認してみましょう。 RequestFormを用意する まず、検索リクエストを雑にバリデーションするSear
第1回では、「Salesforceシステム連携のデザイン考察 1（ニーズとアプローチ）」と題して、連携のニーズとアプローチをお伝えしました。 第2回では、最もニーズの多いと思われる「ビジネスロジック連携／データ連携」に焦点をあて、これまでの経験から外部システムと連携させるための検討ポイントや、Salesforceが備える機能を有効に活用し、具体的なアーキテクチャーをどう考えるかをお伝えしたいと思います。 ※システム連携のアーキテクチャーに正解はありませんので、考え方の一例としてお読みください。
ビジネスロジック（ドメインロジック）をどうやってモデリングして、どうやって実装するかの実践例を公開しました。 RDRA 2.0 ハンドブックの図書館システムの実装例 (github) ビジネスロジックのもとになる業務モデルやビジネスルールのモデリングは、 モデルベースの要件定義手法 RDRA2.0 を使っています。 RDRA 2.0 ハンドブック (Kindle Unlimited会員は無償です) 実装技術は、Java/Spring Boot/MyBatis/Thymeleafを使っています。 JIGという設計の可視化ツールを使って、ソースコードからパッケージ関連図やクラスの一覧を自動生成しています。 JIGリポジトリ 利用方法 RDRA 2.0 ハンドブックを入手 リポジトリRDRA 2.0 ハンドブックの図書館システムの実装例をクローン Gradleタスク bootRunを実行(アプリ
ビジネスロジック層は次のようなクラス(アプリケーションロジックもドメインロジックも1つのクラス)で構成されます。 サービス Dxo アプリケーションロジック メールを送るなどドメインに無関係なロジック ドメインモデルの再利用性を高めるためドメインモデルから分離する アプリケーションロジックをサービスのメソッドにしてしまうとアプリケーションロジックが分散する危険性がある (ドメインロジック) ドメインロジックを()で囲っているのは、ドメインロジックをドメインモデルに持たせた場合、ドメインロジックは、ビジネスロジック層に含まれないためです。 ドメインモデルにドメインロジックが含まれる場合をリッチドメインモデルと呼び、ドメインモデルにドメインロジックが含まれない場合をシンドメインモデルと呼ぶことにします。 ドメイン層ではなく、ビジネスロジック層という言葉を使ったのは、リッチドメインモデル場合、ド
最近のシステム開発は、既に作られたシステムの保守開発とその更改が中心となっています。ところがこのシステム更改には、しばしば失敗例が見受けられます。その原因の一つとして現行システムの理解不足が挙げられます。理解不足によって要件定義漏れなどが起こり、開発がとん挫してしまうのです。 このため、システム更改にあたってはまず現行システムの解析が重要となります。現行解析では、どのようなことを行うべきで、実際にどのように実施されているのでしょうか。現時点では、システムの棚卸しのための情報生成やレガシーコードの正確な仕様解析などが自動化できています。一方で、回復した設計情報へのシステム目的や業務情報の付与などは自動化が困難です。自動化できることとできないことの見極めが解析作業を円滑に進めるうえで欠かせません。 今後はソースコード以外の入力情報を基にした現行解析や、経営者やユーザーにもわかる現行解析へと領域
ビジネスロジック部品 第４章
ビジネスロジック部品 (本体) 第４章 ソフトウェア開発の生産性 一般に、ソフトウェアを開発した経験のない方々は、ソフトウェアの開発を物の製造と同じだと考えたがるが、これは大いなる誤解を発生させる。また、ソフトウェア開発の生産性は簡単に数値化可能であると考えるのも誤りである。そして、ソフトウェア開発の実態に立ち入らずにその生産性を議論するようでは、有効な成果は期待できない。意味をなさない議論が展開されて、生産性の数値が一人歩きをするだけである。これでは、何の実りもない。 この章では、まずソフトウェア開発とは何なのかをある程度深く認識してから、その生産性の正しい計り方について考察してみる。その後で、これまでのソフトウェア開発の歴史を振り返って生産性が向上しているかどうかを調べ、最終的には、生産性を向上させる方法を探ることにする。 この章は、プログラムの中のバブル、すなわち冗長な部分を取りあげ
Android SDKが提供するTestCase 前述のとおり、Android SDKでは「TestCase」クラスの拡張クラスが用意されています。それぞれの拡張クラスはAndroidのコンポーネントのテストをしやすいように拡張されていますので、テスト対象や用途によって使い分けます。 TestCaseクラスを拡張した、「InstrumentationTestCase」「AndroidTestCase」の2つの基底クラスがあり、そのどちらかを拡張したTestCaseがいくつか用意されています。 InstrumentationTestCaseはその名の通り、Instrumentationのインスタンスを持つTestCaseです。Instrumentationは、Androidのシステムをフックしたり、制御するメソッドの集まりです。アクティビティにキーイベントも送信できます。 一方のAndroi
Rails をかじっていくと、主に view と controller がごちゃごちゃしてくる。 あまり考えずに作っていくと以下のような状態になっちゃった view: 様々な action からの遷移で表示したいものを :action で判定したりするコードが増える controller: model から様々な形式の検索方法でデータを取得してきてそれなりの配列とかに加工 model: あまり処理なし。ほとんど空 自分の実感としてはMVCで考えると以下のようなイメージ view: レイアウトがわかるようなレベルで処理を書きすぎない。デザインは css なのかな。 controller: view と model の仲介だから model から取得した値をあれこれいじりすぎずに view に渡す。逆に view からもらったデータを画面遷移とかに必要な最小限のデータだけ見てあとは model
ぼくのかんがえた最強のUsecaseの作り方~あるいはビジネスロジックとはなにかという1つの回答~
ビジネスロジック、Domain層、UseCase。これらはMVVMやMVP、CleanArcitectureなど、3-Layeredアーキテクチャーではよく聞く単語だ。 しかし、いざ設計しようとすると 「つまり、ビジネスロジック/Domain/UseCaseって何？」 「レポジトリから取得したデータをそのまま渡すだけになるんだけど、これでいいの？」 などなど、首をひねりながら設計する人は多いのではないだろうか。かくいう私もその一人だった。 今回の発表では、CleanArchitectureにフォーカスし、「ビジネスロジック/Domain/UseCase is 何」という疑問を紐解いていこうと思う。 具体的には個人で開発しているアプリの「らくでん」の実装を元に、 ・ビジネスロジックってどういうものを指すのか ・Domain層(UseCase)をどのように設計していくか ・何をDomain層に
はじめに 「Controller にビジネスロジックを書くな」と言われることがしばしばあると思います。 この記事では、そもそもそれは何がいけないのか、どうすればいいのかを整理しました。 具体的なコードまでは書いていないですが、各ケースを図で表現して、できるだけ分かりやすいようにまとめました。 「Controller に全部書く」とはどんな状態か 「Controller にビジネスロジックを書くな」の対応の前に、「Controller に全部書く」という状態について整理しようと思います。 この記事で言う「Controller に全部書く」状態とは、MVC を使っていて、Model クラスがデータの入れ物 (多くの場合、DB スキーマとほぼ一致) で、Service クラスが存在せず、プログラムの処理が全て Controller に書かれている状態です。 イメージとしては、以下の図のような状態
ビジネスロジック書くところ無い cakephpでは、Helper,Component,ShellHelper,Cellなどもろもろロジックを使いまわすための機構がありますが、バッチなどを動かすShellと、ウェブ上で動かすcontroller等のソースで、ロジックを共有したいのに既存のものだとロジックを置く場所がないです。 参考 みんな困ってます。 cakephp - How to load a component in console/shell - Stack Overflow どうやってコンポーネントをshellでつかうの？ cakephp 3.0 - Calling a Component function from helper - Stack Overflow どうやってコンポーネントをHelperの中でつかうの？ ということで、Serviceクラスを作ってみました 正直DDD
GraphQLのMutationのビジネスロジックのエラーはどうハンドリングすればいいのか - taiyoh's memorandum
最近調査していた内容のメモ。 GraphQLのJSONレスポンスは data と errors の2つのキーに内容が大別される。 基本的に、期待するレスポンスが返せないときは errors にエラー内容が入るというのがGraphQLでやろうとしていることだが、特にMutationにおけるビジネスロジックのエラーはどう記述すればいいだろうか。 恐らくFacebook的には「ダメです！」とエラーダイアログを表示させて終了なのかもしれないが、世の中のサービスが全部それに倣っているということはなく、エラーとなった要素をクライアント側で特定して赤くしたりエラー文言を添えたりしたい、なんてケースはよくある。自分の担当しているサービスもそんな感じだ。 ひとまずRelayのドキュメントを開いてみる→ Mutations · Relay ざっくりと「レスポンスには（追加・削除含め）変更のあったTypeのオブ
AndroidアプリにStrutsのようなコントローラを導入し，画面制御させるサンプルコード （の試作品。バリデーションやビジネスロジックの骨組み） - 主に言語とシステム開発に関して
AndroidプログラミングのTOPへ 重要なお知らせ： この記事で公開した情報は，AndroidのMVCフレームワーク「Android-MVC」の機能の一部として取り込まれました。 より正確な設計情報や，動作可能な全ソースコードを閲覧したい場合，「Android-MVC」の公式ページより技術情報を参照してください。 AndroidのMVCフレームワーク - 「Android-MVC」 http://code.google.com/p/android-mvc-... Androidアプリの設計に，Strutsのようなアーキテクチャを取り入れよう。という記事。 ただし，Javaにつきものの「XML地獄」は，徹底的に避けるものとする。 いかにシンプルにAndroidアプリの画面制御を管理するか？ Androidアプリは，複数の「Activity」（＝画面）を持つ。 それらActivityどうし
この記事はSwift 5.7以前に書かれたものです。そのため下記のprotocolは型消去せずとも実装可能となっています。 最初にこの文章の結論 この文章は、ロジックを処理する次のような型をアプリケーションの中で定義してみたらどうかな、と考えているのを文章にしてみたものです。 protocol UseCase { associatedtype Parameters associatedtype Success func execute( _ parameters: Parameters, completion: ((Result<Success, Error>) -> ())? ) func cancel() } なぜこんな事を考えているかというと、iOS VIPERアーキテクチャ研究読本（仮）という電子書籍を作ってみたいなと考えていて、まずはサンプルコードを作ろうとしているためです。 V
アプリケーション固有の処理 アプリケーション固有の状態遷移を記述した部分 具体的に示すと アプリケーションが どのような順番で処理するのか。 どこからどのようなデータを取得するか。 データをどのように処理するか。 正常処理の条件はどうするか。 正常処理したあとはどうするか。 エラーの条件はどうするか。 エラーになったときはどうするか。 等を記述した部分 ビジネスロジックで状態遷移が論理的に破綻してしまうとアプリケーションに欠陥が生じる。 このタグの解説についてこの解説文は、すでに終了したサービス「はてなキーワード」内で有志のユーザーが作成・編集した内容に基づいています。その正確性や網羅性をはてなが保証するものではありません。問題のある記述を発見した場合には、お問い合わせフォームよりご連絡ください。
動機 GraphQLを勉強しているとき、 GraphQLが"グラフ"を扱っているのはわかるけどそれによってどんないいことがあるんだろう？ バックエンドにGraphQLを選択した際、ビジネスロジックはどこに表現されるべきなんだろう? という私の疑問にサクッと答えてくれる日本語の文献が少なくともネット上には見つからなかったので、書いてみることにしました。 作るもの いわゆる"TODOリスト"を作ります。TodoistやRememberTheMiik的なあれですね。 いきなり余談ではありますが、何か新しい言語やフレームワーク、DBなどをサクッと試したいときに作るものの題材として、"TODOリスト"は個人的に以下の観点からオススメです。 仕様がイメージしやすい 大抵の方は何らかのTODOリストを使ったことありますよね？ どんなアーキテクチャでも大抵１日以内に完成する 慣れないアーキテクチャであまり
ビジネスロジック = ドメインロジック
Landscape トップページ | < 前の日 2005-12-26 2005-12-27 次の日 2005-12-28 > Landscape - エンジニアのメモ 2005-12-27 ビジネスロジック = ドメインロジック 当サイト内を Google 検索できます * ビジネスロジック = ドメインロジックこの記事の直リンクURL: Permlink | この記事が属するカテゴリ: [プログラミング] 2005-12-12 の「ビジネスロジックとは」にいくつかコメントや指摘を頂いた。 - ビジネスロジック = ドメインロジックはてなブックマーク - ビジネスロジックとは http://b.hatena.ne.jp/entry/http://sonic64.com/2005-12-12.ht ... Dice-Kei 『ビジネスロジックをもっと簡単に…『手続き』とか？』 naoya
[.NET Framework 4/4.5][C# 5] 非同期で動くビジネスロジックを作る - biac の それさえもおそらくは幸せな日々@nifty
C# Advent Calendar 2011 参加記事 「Win8 に備えて async / await を勉強してみよう」 で書いたように、 async / await が使えれば非同期処理のコーディングがあっさり出来てしまいます。 たとえば今まで 3秒も掛かっていた UI のイベントハンドラーに async / await を付けるだけで、 ほぼ 0秒で応答が返ってくるようになります (画面が書き換わるのは、 やっぱり 3秒後ですけど)。 ※ ユニットテストのコードでイベントハンドラーの雰囲気を出してみた。 ※ 「LongTimeMethodTest_既存のUIのイベントハンドラーの例だと思ってほしい」は、実行に 3秒。 ※ 「LongTimeMethodAsyncTest_UIのイベントハンドラーはこんな感じになる」の方は、0mS (1ミリ秒掛かっていない)。 こういう嬉しいことが
![[.NET Framework 4/4.5][C# 5] 非同期で動くビジネスロジックを作る - biac の それさえもおそらくは幸せな日々@nifty](https://cdn-ak-scissors.b.st-hatena.com/image/square/92f866ccf082318c875e3fe02595e204940efa62/height=288;version=1;width=512/http%3A%2F%2Fbluewatersoft.cocolog-nifty.com%2Fblog%2Fimages%2F2011%2F12%2F09%2F20111209_asyncmethod01a.png)
概要 ビジネスロジック（business logic）とは、業務システムの中で、具体的な業務で扱う様々な実体（商品、顧客、在庫など）を表現し、また、それらの関係や処理の方法、業務の流れなどをデータモデルやプログラムコードなどとして実装した部分。 いわゆる「3階層システム」（3-tier system）では、プレゼンテーション層（ユーザーインターフェース層）とデータアクセス層（データベース層）の中間に位置し、「ビジネスロジック層」あるいは「アプリケーション層」と呼ばれる。アプリケーション固有の処理やルールが記述される。 ビジネスロジックは現実の業務や事業におけるビジネスルールやワークフローが反映され、システムごとの固有性が高い。実際の業務をよく反映し、あるいはその効率化に資するよう、事前の入念な調査や設計をもとに実装されるべきとされる。 なお、Webアプリケーションシステムでは、ビジネスロジ
簡単に書くよ ビジネスロジック（英：business logic）とは そのシステムにおける、システム固有の処理を行う部分……的なニュアンスだけど具体的に何を指すかは結構あいまいで、みんな何となくのフィーリングで使っている用語。 もう少しざっくりと書くと システムにおける実際のお仕事部分のこと です。 サクッと一言で説明すると システムにおいて、そのシステムとしての実際のお仕事をする部分 が「ビジネスロジック」です。 ちなみに「ロジック」は「プログラムにおける処理の内容、手順、方法」ね。 例えば、そうですね。 ピヨ太君が「ピヨピヨ業務システム」を作ったとしましょう。 ピヨピヨ業務システムは、ぺちぺち情報を入力すると、あれやこれやの処理が行われて、その結果がデータベースに登録されるシステムです。 ピヨピヨ業務システムを見たピヨ子さんは、ピヨ太君に ピヨピヨ業務システムって何をするシステムなの
前回紹介した Model は、あくまで JavaBeans であり、それ自体に永続化の機能はありません。 BigTable への Model の永続化、および BigTable からの Model の取得といった persistence に関する処理は、Model 以外の別のクラスで定義する必要があります。 また、FrontController（後述）は画面遷移を扱うクラスであり、Struts の Action クラス同様、ビジネスロジック及び persistence の処理を定義すべきではありません。 slim3 では、ビジネスロジック及び persistence の処理を行うクラスとして、”Service”というクラスを定義・使用します。 １．Serviceの作成方法 こちらの記事の、”gen-service”をご確認下さい。 ※gen-gwt-service については、後日触れます
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「ビジネスロジック」とは何か、どう実装するのか - Qiita
削除のビジネスロジックをドメイン層に閉じ込める簡単で強力な「DeletableIDパターンの紹介」
ビジネスロジック層内部の2つの実装パターンを比較 選択時に考えたい、アプリケーション設計の観点
3層アーキテクチャで最も謎な「ビジネスロジック層」 “システムのコア”をゲーム「リバーシ」で解説
Android SDKでビジネスロジックのテストを自動化するには
アプリケーションアーキテクチャ理解に必要な“3層構造” プレゼンテーション層・ビジネスロジック層・データアクセス層それぞれの役割
「ビジネスロジックの処理は2つに分類すると整理しやすい」 4つの例から考える、プレゼンテーション層・データアクセス層の見分け方
reduxでビジネスロジックをゴリゴリ書く
ビジネスロジック記述の必須知識、AngularJSの「サービス機能」を理解しよう
DAOとO/Rマッピングとビジネスロジックと - それはBooks
Rails サービスの事業拡大期におけるビジネスロジックを書く場所と書き方 - てくすた
Salesforceシステム連携のデザイン考察 2（ビジネスロジック連携／データ連携の検討ポイント）
ビジネスロジックのモデリングと実装 - ソフトウェア設計を考える
ビジネスロジック層とドメインモデル - ひがやすを技術ブログ
第7回 ビジネスロジックの可視化と現行資産の棚卸しで自動化ツールが活躍
Android SDKでビジネスロジックのテストを自動化するには
ビジネスロジックをどこに書くか - KodaNote
「Controller にビジネスロジックを書くな」の対応パターン - Qiita
cakephp3 ビジネスロジックを書くためにServiceクラスを作る - Qiita
Swiftでビジネスロジックを実行するUseCaseのprotocolを作りたい話 2019 - Qiita
ビジネスロジックとは コンピュータの人気・最新記事を集めました - はてな
GraphQLが"グラフ"であることを利用してビジネスロジックを入れ込んでみる - Qiita
ビジネスロジックとは 【 business logic 】 - 意味/解説/説明/定義 ： IT用語辞典
ビジネスロジックとは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
【slim3】ビジネスロジックとしての”Service” - The HIRO Says