タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「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 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に代数的データ型などの関数型のパラダイムを加えたよりタイプセーフな関数型DDDを紹介します。 本セッションではドメインモデリングによって発見したモデルやビジネスロジックをソフトウェアに反映する際により型を重視した設計を加えます。 型で表現する範囲が広がることでビジネスロジックをより明確にコードで表現できるようになります。 さらには型で表現されているためコンパイルフェーズで気付けるミスが増え、ソフトウェアの品質向上にもつながります。 関数型の考えをいれるといってもただ単にHaskellなどに代表される関
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか？ 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか？は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか？」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。次に、ビジネスロジックの実装方法について紹介します。前回はこちらから。 ビジネスロジックの実装の2つのパターン 大嶋勇樹氏：ここまでの流れは、「そもそも3層アーキテクチャって何だっけ？」というところから、特に「真ん中のビジネスロジックって何だっけ？」と（いう話）、「例えば、このあたりがビジネスロジックだよね」と（いう話）。（そして）「ビジネスロジックの中には、ドメインロジックとユースケースの2種類があると考えるとわかりやすいですよ」というところまで話してきました。 ドメインロジックは、システム都合ではないコアなルールみたいなもので、ユースケースは処理の流れを実現することです。これを踏まえて
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。ここからは、3層アーキテクチャの典型例について話し、ビジネスロジック層について深掘りして紹介します。前回はこちらから。 3層アーキテクチャ+MVCの通信の流れ 大嶋勇樹氏：こうやって話してくると、具体的に「じゃあコードをどういうふうに書くの？」「どういうクラスで書くの？」ということを疑問に思うかもしれません。派生形やちょっと違う例もいろいろありますが、典型的な例を1個書いています。 （スライドを示して）これが3層アーキテクチャとMVC（Model、View、Controller）ともいえる典型例です。クラス名のつけ方はいろいろあります。これはどういう構造になっているかというと、まずCont
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。続いて、3層アーキテクチャそれぞれの役割について紹介します。前回はこちらから。 本セッションにおける「3層アーキテクチャ」の定義 大嶋勇樹氏：ということで、ここまでで「そもそもアプリケーションアーキテクチャとは何でしょう」という話をしました。ここからが本題的なところで、まず最も基本、最も基本というのは僕の意見ですが、3層アーキテクチャについて話していこうと思います。なにか気になる点があれば、Q&Aに気軽に（質問して）もらえればそちらも回答します。 では、3層アーキテクチャについてに入っていこうと思います。3層アーキテクチャと言われた時に想像するものは、少なくとも私の場合は2つあります。 （
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。さらに、ビジネスロジック層の役割について深掘りします。前回はこちらから。 リクエストの形式チェックはビジネスロジック層の役割か？ 大嶋勇樹氏：（スライドを示して）続けて「これはビジネスロジック？」（というもの）をもう少し見ていこうと思います。2つ目として、リクエストの形式チェックがあります。 例えば、リクエストの必須パラメーターが足りているかとか、データサイズは決められた範囲内かとか、そういうチェックがあると思いますが、個人的にこれはプレゼンテーション層でチェックすべきものだと思っています。 なぜかというと、リクエストは利用者とのインターフェイス、利用者との境界での約束事に対するチェックな
ビジネスロジック（ドメインロジック）をどうやってモデリングして、どうやって実装するかの実践例を公開しました。 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を実行(アプリ
はじめに 「Controller にビジネスロジックを書くな」と言われることがしばしばあると思います。 この記事では、そもそもそれは何がいけないのか、どうすればいいのかを整理しました。 具体的なコードまでは書いていないですが、各ケースを図で表現して、できるだけ分かりやすいようにまとめました。 「Controller に全部書く」とはどんな状態か 「Controller にビジネスロジックを書くな」の対応の前に、「Controller に全部書く」という状態について整理しようと思います。 この記事で言う「Controller に全部書く」状態とは、MVC を使っていて、Model クラスがデータの入れ物 (多くの場合、DB スキーマとほぼ一致) で、Service クラスが存在せず、プログラムの処理が全て Controller に書かれている状態です。 イメージとしては、以下の図のような状態
この記事は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リストを使ったことありますよね？ どんなアーキテクチャでも大抵１日以内に完成する 慣れないアーキテクチャであまり
ビジネスロジックとは何か？
業務システムの設計/開発/運用の文脈での、ビジネスロジックについて考察してみたいと思います。 ソフトウェア設計についての本やブログ記事などで、「ビジネスロジックは重要である」ということは、何度も何度も言われていて常識になっていて否定する人はほとんど居ないと思います。この点については文字通りの意味で納得するところなのですが、「ビジネスロジック」というのは、何なのでしょうか？ 実際のところ ビジネスロジックとは何か？と問われて思いうかべる事は人によって異なるかもしれません。 要件定義書に書かれていることがビジネスロジック？ 基本設計書に書かれていることがビジネスロジック？ ○○テーブルの××カラムと□□テーブルの△△カラムを同一トランザクションで更新することがビジネスロジック？ あるページの○○ボタンをクリックしたら、行を削除するということがビジネスロジック？ どうも捉え所が無い感じです。 W
Goの初心者から上級者までが1年間の学びを共有する勉強会、「GeekGig #1 ～Goと私の一年～」。ここで株式会社Showcase Gigの照井氏が登壇。Goを用いたPOS連携実装で学んだことを紹介します。 アジェンダと自己紹介 照井寛也氏（以下、照井）：「POSレジとGo」というタイトルでさっそく発表します。今回話す内容ですが、チャネルとgoroutineを、実際のビジネスロジックでどのように使っているかの事例の共有と、そこから得た学びを共有します。 アジェンダとしてはこのようなかたちになっています。まず自己紹介をし、Showcase Gigが提供する次世代店舗プラットフォーム「O:der（オーダー）」とPOSレジの関係性、そこからチャネルとgoroutineを用いたPOS連携開発について話します。あとはそれらを開発実装したうえでの学びを共有します。 というところで、さっそく自己紹介
Effortless Real-time GraphQL API with serverless business logic running in any cloud Vladimir Novick ・ Feb 5 '19 ・ 12 min read この記事では、サーバーレスのビジネスロジックを使用して、楽にリアルタイムGraphQL APIを作成し、それをあらゆるクラウドにデプロイする方法を紹介します。釣り記事のように聞こえますか？楽にってどういうこと？全く何もしなくてもいいという訳ではありません。あなたがGraphQLに精通しているか、またはそれについて聞いたことがある、そしてどうやってGraphQLサーバを書き始めるのか疑問に思っているならば、あなたは我々があなた自身のGraphQLサーバをつくると思うかもしれません。またクラウドの導入、サーバーレス機能を扱うことになるでしょう。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「ビジネスロジック」とは何か、どう実装するのか - Qiita
削除のビジネスロジックをドメイン層に閉じ込める簡単で強力な「DeletableIDパターンの紹介」
ビジネスロジック層内部の2つの実装パターンを比較 選択時に考えたい、アプリケーション設計の観点
![[VS Code]タブのカスタムラベル設定でpage.tsx、layout.tsxなどのファイルを見やすくする | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/611914e4c074abe947efa5c820fc1646e6c60a0a/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2020%2F06%2Fvscode-2020-eyecatch-1200x630-1.png)
3層アーキテクチャで最も謎な「ビジネスロジック層」 “システムのコア”をゲーム「リバーシ」で解説
アプリケーションアーキテクチャ理解に必要な“3層構造” プレゼンテーション層・ビジネスロジック層・データアクセス層それぞれの役割
「ビジネスロジックの処理は2つに分類すると整理しやすい」 4つの例から考える、プレゼンテーション層・データアクセス層の見分け方
ビジネスロジックのモデリングと実装 - ソフトウェア設計を考える
「Controller にビジネスロジックを書くな」の対応パターン - Qiita
Swiftでビジネスロジックを実行するUseCaseのprotocolを作りたい話 2019 - Qiita
GraphQLが"グラフ"であることを利用してビジネスロジックを入れ込んでみる - Qiita
Goを用いたPOS連携実装の学びとTIPS チャネルとgoroutineをどうビジネスロジックに当てはめるか
サーバーレスのビジネスロジックを任意のクラウドで楽に実行できるリアルタイムGraphQL API
yazikun.hatenablog.com
www.winticket.jp
www.afpbb.com
togetter.com
tecstaff.jp
www.47news.jp