Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に…
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
ビジネスロジックを「型」で表現する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
「ビジネスロジック」と「例外」
「秋の旬なアーキテクチャLT会」での発表資料です 「ビジネスロジック」と「例外」、というテーマでまとめてみました
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。続いて、3層アーキテクチャそれぞれの役割について紹介します。前回はこちらから。 本セッションにおける「3層アーキテクチャ」の定義 大嶋勇樹氏：ということで、ここまでで「そもそもアプリケーションアーキテクチャとは何でしょう」という話をしました。ここからが本題的なところで、まず最も基本、最も基本というのは僕の意見ですが、3層アーキテクチャについて話していこうと思います。なにか気になる点があれば、Q&Aに気軽に（質問して）もらえればそちらも回答します。 では、3層アーキテクチャについてに入っていこうと思います。3層アーキテクチャと言われた時に想像するものは、少なくとも私の場合は2つあります。 （
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。さらに、ビジネスロジック層の役割について深掘りします。前回はこちらから。 リクエストの形式チェックはビジネスロジック層の役割か？ 大嶋勇樹氏：（スライドを示して）続けて「これはビジネスロジック？」（というもの）をもう少し見ていこうと思います。2つ目として、リクエストの形式チェックがあります。 例えば、リクエストの必須パラメーターが足りているかとか、データサイズは決められた範囲内かとか、そういうチェックがあると思いますが、個人的にこれはプレゼンテーション層でチェックすべきものだと思っています。 なぜかというと、リクエストは利用者とのインターフェイス、利用者との境界での約束事に対するチェックな
マイクロサービス化するならリビルドで！ビジネスロジックをGoで書き直してわかったこと - MonotaRO Tech Blog
この記事では モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog のうち、主にアーキテクチャにおける詳細について紹介します。 自己紹介 マイクロサービス化について 課題を認識する スコープと技術選定 ゴールイメージを共有する 既存コードから分かった問題点 曖昧なデータ構造 処理フローの混在 アドホックなデータ取得 効果的な改善を行う 処理フローを分割する N+1問題とロジックの独立性を考慮した設計 安全に移行する 実行時のデータを取る 新旧比較による検証 まとめ 自己紹介 藤本 洋一 プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム 楽天、SaaSベンチャーを経て、モノタロウに入社してマイクロサービス化にとりくむエンジニアの話 2019年5月入社。商品検索基盤のマイクロサービスと
はじめに FlutterでRiverpodを使った開発をしていると、必ず遭遇する設計上の疑問があります。 「RepositoryクラスにRefを渡してもいいの？」 この疑問は単純そうに見えて、実はRiverpodの設計思想とクリーンアーキテクチャの原則が交差する重要なポイントです。本記事では、この問題を深く掘り下げ、なぜアンチパターンとされるのか、そしてどのような設計が推奨されるのかを実践的な観点から解説します。 TL;DR ❌ NG: ビジネスロジック層（Repository/Service/UseCase）にRefを渡す ✅ OK: Provider関数内でRefを使い、必要な依存関係のみを注入 理由: 単一責任の原則、テスタビリティ、フレームワーク非依存性の維持 解決策: コンストラクタインジェクション、メソッド引数、Interceptorパターン 例外: ドメインロジックが薄いシン
fast-checkとneverthrowのPBT+Result型で 堅牢なビジネスロジックを実現する
2025/5/23 TS Kaigi 2025登壇資料
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「Controller にビジネスロジックを書くな」と言われることがしばしばあると思います。 この記事では、そもそもそれは何がいけないのか、どうすればいいのかを整理しました。 具体的なコードまでは書いていないですが、各ケースを図で表現して、できるだけ分かりやすいようにまとめました。 「Controller に全部書く」とはどんな状態か 「Controller にビジネスロジックを書くな」の対応の前に、「Controller に全部書く」という状態について整理しようと思います。 この記事で言う**「Controller に全部書
Goの初心者から上級者までが1年間の学びを共有する勉強会、「GeekGig #1 ～Goと私の一年～」。ここで株式会社Showcase Gigの照井氏が登壇。Goを用いたPOS連携実装で学んだことを紹介します。 アジェンダと自己紹介照井寛也氏（以下、照井）：「POSレジとGo」というタイトルでさっそく発表します。今回話す内容ですが、チャネルとgoroutineを、実際のビジネスロジックでどのように使っているかの事例の共有と、そこから得た学びを共有します。 アジェンダとしてはこのようなかたちになっています。まず自己紹介をし、Showcase Gigが提供する次世代店舗プラットフォーム「O:der（オーダー）」とPOSレジの関係性、そこからチャネルとgoroutineを用いたPOS連携開発について話します。あとはそれらを開発実装したうえでの学びを共有します。 というところで、さっそく自己紹介に
要件定義の障壁。あるいはビジネスロジックの複雑さが招くプロジェクトの悲劇：プロジェクトマジック：オルタナティブ・ブログ
現時点でシステム構築の最大の障壁は 「ユーザー（業務部門）の人間であっても、システムに実装したい要件を明確に語れないこと」 である（断言）。 一応確認しておくと、「どんなシステムを作ってほしいか？」を語る責任は、ユーザー側にあると一般的に言われている。外部のベンダーにシステム構築を発注する際は、ベンダーではなく、発注者の責任となる。 だが、近年ほとんどの業務部門はこの責任を果たせない。自分たちが欲しいシステムをこと細かに説明できるユーザーは「その業務の主」みたいな方に限られるし、そういう方がいないケースも多い。 もう少し補足する。 「自分たちがやっている業務を、自分が担当している作業の上流も下流も含めて、通しで説明する。何のためにその業務をやっているとか、プロセスの途中で誰がサボると何が起こるか、などを理解し、部外者に説明する」 はできて当たり前のように思うかもしれないが、これがちゃんとで
はじめに 今回は Go 言語で OpenAPI のコード自動生成を試してみたいと思います。「コード自動生成って何だ？」という方や「OpenAPI ってそもそも何？」という方にもわかりやすく解説していこうと思います。 まず、OpenAPI でコード自動生成ができると以下の嬉しいことがあります。 ただの作業になりがちなモデルの作成が自動化できる 仕様書通りにモデルや API インターフェースが自動生成されるので、バグが入りにくい 仕様書通りのリクエスト・レスポンスかどうかを簡単にバリデーションできる その結果、ビジネスロジックに集中する開発ができる です。 今回のサンプルコードはこちらに置いてあります。 OpenAPI とは OpenAPI とは、 REST API の定義を記述する仕様のことです。例えば、以下は「GET /users API を叩いたら200ステータスで id, name を
![[Go] OpenAPI コード自動生成でビジネスロジックに集中する開発へ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/b0c592584a460c672674fe32a7f787e47fda3bd4/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCR28lNUQlMjBPcGVuQVBJJTIwJUUzJTgyJUIzJUUzJTgzJUJDJUUzJTgzJTg5JUU4JTg3JUFBJUU1JThCJTk1JUU3JTk0JTlGJUU2JTg4JTkwJUUzJTgxJUE3JUUzJTgzJTkzJUUzJTgyJUI4JUUzJTgzJThEJUUzJTgyJUI5JUUzJTgzJUFEJUUzJTgyJUI4JUUzJTgzJTgzJUUzJTgyJUFGJUUzJTgxJUFCJUU5JTlCJTg2JUU0JUI4JUFEJUUzJTgxJTk5JUUzJTgyJThCJUU5JTk2JThCJUU3JTk5JUJBJUUzJTgxJUI4JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0xYWNkYjEzYmRjYWQxNzNjYmJkNzE0MzE4NWZkYTVmOA%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDBueWFuY2h1JnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0yZTgxOGFhNTMwZjA4MWE2ZjI1YmJhYWZkZGQ2MWVlZA%26blend-x%3D120%26blend-y%3D445%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-IOODieODr-ODs-OCtA%26txt-width%3D972%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25233A3C3C%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D134%26txt-y%3D546%26s%3D5cc6b0d3245a0c88f595768c1de5a4eb)
ビジネスロジックとは何か？
業務システムの設計/開発/運用の文脈での、ビジネスロジックについて考察してみたいと思います。 ソフトウェア設計についての本やブログ記事などで、「ビジネスロジックは重要である」ということは、何度も何度も言われていて常識になっていて否定する人はほとんど居ないと思います。この点については文字通りの意味で納得するところなのですが、「ビジネスロジック」というのは、何なのでしょうか？ 実際のところ ビジネスロジックとは何か？と問われて思いうかべる事は人によって異なるかもしれません。 要件定義書に書かれていることがビジネスロジック？ 基本設計書に書かれていることがビジネスロジック？ ○○テーブルの××カラムと□□テーブルの△△カラムを同一トランザクションで更新することがビジネスロジック？ あるページの○○ボタンをクリックしたら、行を削除するということがビジネスロジック？ どうも捉え所が無い感じです。 W
『秋の旬なアーキテクチャLT会』というイベントで「ビジネスロジックと例外」というタイトルで発表してきました - Magnolia Tech
speakerdeck.com 吉祥寺.pmや、設計ナイトでもたびたび登壇されている工藤由美さんの主催による『秋の旬なアーキテクチャLT会』というイベントに誘われたので、招待枠、ということでLTしてきました 秋の旬なアーキテクチャLT会 「旬なアーキテクチャ」、ということでもっとミドルウェアとか、サービスとかそういう話をした方がいいのかなーとも思ったのですが、以前から何度かブログにも書いている「コードに色はない」という話を膨らませて、「通常」パターンと、「例外」パターンを分離しないと、「例外」パターンは増え続けて全体を圧迫するよ、意識的に設計しようね、という話でまとめてみました 感想をお待ちしております 次回予告を載せていますが、前回の登壇から6年経っていることが判明したので、次回は6年より短くなるように頑張ります 主催の工藤由美さん、スポンサーの株式会社キッカケクリエイション様、このよう
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
削除のビジネスロジックをドメイン層に閉じ込める簡単で強力な「DeletableIDパターン」の紹介
ビジネスロジック層内部の2つの実装パターンを比較 選択時に考えたい、アプリケーション設計の観点 | ログミーBusiness
3層アーキテクチャで最も謎な「ビジネスロジック層」 “システムのコア”をゲーム「リバーシ」で解説
アプリケーションアーキテクチャ理解に必要な“3層構造” プレゼンテーション層・ビジネスロジック層・データアクセス層それぞれの役割
「ビジネスロジックの処理は2つに分類すると整理しやすい」 4つの例から考える、プレゼンテーション層・データアクセス層の見分け方
Riverpod設計考察：ビジネスロジック層にRefは渡すべきか？クリーンアーキテクチャとの境界線
「Controller にビジネスロジックを書くな」の対応パターン - Qiita
Goを用いたPOS連携実装の学びとTIPS チャネルとgoroutineをどうビジネスロジックに当てはめるか | ログミーBusiness
[Go] OpenAPI コード自動生成でビジネスロジックに集中する開発へ - Qiita
kinski2011.hatenadiary.org
x.com
repub.hatenablog.com
oinagoya.com
withnews.jp
daisuke1.vp.bex.jp