常連

### 実現したいこと
フロントエンドをVue、バックエンドをJavaでWebアプリを作成しています。
バックエンドでのAPIの実装のパターンで2つのケースを想定しているのですが、どちらが一般的な手法であるかを知りたいです。

### 発生している問題・分からないこと
複合的なデータが更新されるケースでのAPIの実装方法がわからないです。

例えば、販売管理システムを考えると、
お客様からの注文を受けた時点で営業担当が何らかのフォームにデータを入力することで、お客様の情報や注文情報などが顧客テーブルや注文テーブルにインサートされると思います。

1つのフォーム処理で複数のテーブルに更新が走るケースでの実装方法ですが、
①バックエンドのAPIをREST APIで実装していた場合、以下のようなURIになると思います。
/api/customer (顧客の新規作成)
/api/order (注文の新規作成)
このような場合、フロントエンドでは顧客のデータを更新するためのAPIをそれぞれ2回呼び出すのでしょうか？

②もしくは複合データモデルを作っておいて、
/api/orderreceive
のようなAPIを一度だけ呼び出したら、その中で顧客の新規作成も注文の新規作成も行われるような形でしょうか？

①だとフロント側の呼び出しが冗長になるのと、API呼び出しを繰り返すことでパフォーマンスに悪影響が出るのではと思っていて、
②だとバックエンドをREST APIで実装していた際に、RESTの原則に反する実装になってしまわないかと思っています。

私はWeb開発初心者のため、認識に間違いがあれば、指摘いただけますと幸いです。また、情報に不足があれば、可能な限り補足しますので、コメント頂けたらと思います。よろしくお願いします。



### 該当のソースコード

```
特になし
```

### 試したこと・調べたこと
- [x] teratailやGoogle等で検索した
- [ ] ソースコードを自分なりに変更した
- [ ] 知人に聞いた
- [x] その他

##### 上記の詳細・結果
書籍等もいくつか確認しましたが、初心者向けの書籍では求めている情報を見つけられませんでした。

### 補足
特になし

フロントエンドとバックエンドのデータをやりとりする際のAPI実装について

## 1.概要

データの操作を行うクラスに、例えばcsvやjson形式のファイルに対する入出力を行うメソッドを実装するべきなのか悩んでいます。

ほかの有名なパッケージではデータをファイルに保存するメソッドはクラス内で実装されています。
一方ソフトウェア工学に基づけばファイルに保存するメソッドはクラス外に実装するべきだと思われます。

どちらの実装も可能です。
将来的なクラスの改変を想定されるときどちらの実装が望ましいでしょうか？

## 2.背景、状況

私は仕事の効率化のために個人的に少しばかりPythonを触っているものです。
検索や並び替えなど簡単なデータの操作を行うクラスを実装しようと考えています。
現時点ではファイルからデータを読み取ることをほとんど前提としています。

想定している前提状況

* クラス外からファイルに保存するのに必要なデータを完全に復元できるだけの情報にアクセスできる
* ただしクラス外から得られるデータはそのままでは適切にファイルに保存できず、保存に際してクラス内での実装に依存した処理が必要になる
  * 例えばクラス初期化に際して与えたlist[float]の数列がクラス外からアクセスするとnumpy.ndarrayとして得られるなど

問題は上記の前提状況でクラス外とクラス内どちらにファイルに保存するメソッドを実装するべきかというものです。

## 3.調査したこと

### 3.1ほかのパッケージでの実装

pandasやほかの自分が利用しているパッケージを3つほど思いつく限り参考にしてみたところ、すべて入力する処理は独立した関数として分割されていますが、出力はインスタンスメソッドとして実装されていました

```python
# pandasの場合
# ファイルからの読み込み(クラスとは独立した関数)
dataframe : pandas.DataFrame = pandas.read_csv("data.csv")
# ファイルへの出力(インスタンスメソッド)
dataframe.to_csv("data.csv")

# sqliteの場合
# dbへの接続(クラスとは独立した関数)
conn : sqlite3.Connection = sqlite3.connect("data.db")
# dbへの書き込み(インスタンスメソッド)
conn.commit()
```

### 3.2ソフトウェア工学的な原則

自分は最近になってSOLID原則などを知るようになった程度なので以下の考えはきちんと理解できていない人間のものだと思います。

SOLID原則における単一責任の原則に基づけば、考えているクラスはデータの改変や操作に集中するべきで、データの保存に関しては分割するべきであるように思われます。
~一方でデータの操作に付随してファイルの入出力はほとんど必要な作業であるので、凝集度を上げるために一つにまとめるべきなのか判断できません。~ 
凝集度を勘違いしていました。凝集度の視点では操作と保存が分割することは欠点にはならないと理解しました。

参考1でもデータを取り扱うクラスと保存するクラスで分割しているようです。

参考 :
* 1.[きれいなコードを書くためにSOLID原則を学びました① \~単一責任の原則\~](https://qiita.com/suzuki0430/items/b13c7c1f637e7cd2146d)
* 2.[設計におけるオブジェクトの責務分配に有効なものさし -凝集度と結合度-](https://www.ogis-ri.co.jp/otc/hiroba/technical/Cohesion_Coupling/Cohesion_Coupling.html)

## 4.自分なりの考え

ファイルからインスタンスを作成する際(入力時)にはクラスのインターフェースに従って入力すればよいので分割するのは簡単ですが、出力する側も分割する場合はクラスの内部につよく依存した形に実装されるように思われます。
例えば数列をクラスの中ではNumpy.ndarrayで保存していた場合、これらをjson形式で保存する関数は数列の部分をlist形式にキャストして保存する必要があります。これはクラス外の実装がクラス内の実装に強く依存しており結合度の高い実装になってしまうように思われます。
したがって自分が実装するならクラスの内部にファイルの入出力にかかわるメソッドを実装します。

先に述べた通り、自分は最近になってSOLID原則などを知るようになった者で上記の自分の考えが正しいのか全く自身がありません。
周りには質問できるようなひとがいないためこちらで質問させていただきます。皆さんのご意見を伺いたいです。

将来的なクラスの改変も予想されるときに
1. クラス外にファイルへの入出力のメソッドを実装する
2. クラス内にファイルへの入出力のメソッドを実装する
どちらがより**理想的で望ましい**実装方法でしょうか?

よろしくお願いいたします。

## 6.最後に

またteratailでの質問はこれが初めてなので質問場所が適切でなかった場合や、タグ付けが正しくないなどあるかもしれません。
その際はご指摘の上、ご容赦頂ければ幸いです。

データクラスがファイルへの入出力の責任を持つべきか？

前提
現在、要件定義フェーズを任されています

発生している問題・エラーメッセージ
要件定義書を書く際、「機能」をどう捉えるとうまく要件定義ができるのかがわからず、自信のないまま作成している状態です。
要件定義を行う際の「良い思考法」、「参考となる書籍・情報源」、または要件定義をうまく行うための「トレーニング方法」など、要件定義のスキルを向上させる一助となるものを教えていただけないでしょうか？

調査したこと
UML図として、状態遷移図やDFD、シーケンス図など様々な観点で機能を捉え、記述する方法があるということを調査しました。

※意図的に内容が抹消された質問 という修正依頼が来ていますが、そのようなことはしておりません。ご安心ください。

要件定義のスキルを向上させたい

### わからないこと、回答してほしいこと
AndroidアプリをKotlinで開発する際、DB接続やIO処理のような一般的に重い処理は非同期で行うような設計思想になっていると思うのですが、仮にinsertが失敗したとか、DBにおいて重複禁止項目のバリデーションエラーに引っかかったなどは、どのようにユーザーに伝えるのが一般的なのかわからないのですが、
こういったアプリの基本的な処理についてのサンプル(入門)プログラムなどは公式から提供されていないのでしょうか？

# 補足、前提
(そもそもDBサーバーに接続に行くのがスマホからだと微妙でAPIサーバーを立てろみたいな意見もありそうですが、すでに利用しているソフトウェアについて、モバイル対応とかもあるとは思うので。。。)

## 関連してUIのトーストについて
以前自分は、トーストは非推奨で、スナックバーを利用すべきというのを見た記憶があり、今回質問の際に再検索してみたところ、以下の内容がヒットしました。
https://developer.android.com/reference/android/widget/Toast

内容からして私が以前確認した、トーストは非推奨というのは誤訳かなにかを確認しただけなのかなと思うのですが、特に理由なくトーストを利用してよいのでしょうか？

## 質問内容のおさらい
非同期処理の実行結果に対してUIに伝えるためのサンプルなどはあるでしょうか？
ユーザーエクスペリエンスのために、UIを思うように動かせないような処理(例えばポップアップによる選択)なども極力してはいけないという認識ですが、
サーバーとの処理はどのくらいかかるかわからず、画面遷移や応答の確認を待たず、即アプリを終了するなどのユーザー操作が考えられますが。

こういうアーキテクチャというか、スマホアプリの設計をする上で必須レベルの情報ってどこで参照すればよいのでしょう？

# お詫び
※話したいことが多すぎてまとまりがないと感じるかもしれませんが、これでも一つの議題に絞ってそれ以外の内容は省いているつもりです。
恐縮ですがよろしくお願いします。

AndroidアプリにおけるDB処理のインタラクティブな

日頃メソッドを作るとき、パラメータがプロパティに存在するものはメンバを参照、そうでない場合は引数を追加するというような規則でコードを書いていますが、これってベストプラクティスなんでしょうか？

私としては、ユーザが必要最小の単位でパラメータを渡せれば楽だと、書く側もプロパティで使いまわせれば余計なパラメータの再定義を割けて楽だと、そのように思っていました。

しかし、いっそパラメータを引数に明示することでメソッドの処理が何のデータを要しているかが明確になったり、メソッド単位での単体テストが楽になるかもといった反対の視野もあるのかなと考えてポリシーを決めあぐねてしまいました。

もしそういった、広く共有される知見に沿ってないなら是正したいので質問しました。
特にそういうのがなければ個人的なご意見でも結構です。

OOPでメソッドへパラメータ受渡しに引数とプロパティのどちらを使うか

あるユーザーのリクエストから別のユーザーの情報を更新してもいいのでしょうか。
例えば、Webアプリのゲームを作っていて、
あるユーザーから別のユーザーとバトルするというリクエストが送られてきた場合、自分と相手のHPを減らします。
このとき同じリクエスト内で自分のHPと相手のHPを更新してしまうと、別のユーザーの情報を更新できることになってしまいますが問題でしょうか？

同じリクエスト内では相手のユーザーの更新はせず攻撃を受けたイベントだけを記録し、相手ユーザーからのリクエストがあったときにイベントをまとめて処理する。などをしたほうがいいのでしょうか？

よろしくお願い致します。

あるユーザーのリクエストから別のユーザーの情報を更新してもいいのか

### 前提

現在LaravelをAPIサーバーとして、認証にLaravel Sanctumを使ってNextjsでフロントエンドの構築を行なっています。

- バックエンド → api.ドメイン (EC2 auto scale) ...リポジトリA
- フロントエンド(要ログイン) → app.ドメイン (Vercel isg + csr + ssr) ...リポジトリB 
- ランディングページ(非ログイン) → ドメイン (Vercel ssg + isg) ...リポジトリC

ここまで全く問題なく所謂よくある設計です。≒ ベストプラクティス

さらにマルチログインに関してもguardを使うことでユーザー用と管理者用でログインセッションを分けることができます

---

ここからが質問内容であり
管理者サイトを作るための選択肢がいくつか存在します。

#### 1. Laravel製のリポジトリAで管理しbladeファイルを返す

api.ドメイン/admin以降にアクセスした場合、bladeファイルを返します

```php　[web.route]
Route::middleware([])->group(function () {
    Route::prefix('admin')->group(function(){
        Route::get('/', function(){
            return blade file
        });
    });
});
```
**メリット**
- 他2つに比べてリポジトリが増えないので管理が楽。
- ユーザーが操作するようなリッチな機能や操作性も必要なく、サービスクラスやリポジトリクラスを使い回すことができる。
- サーバーが増えない。

**デメリット**
- api.ドメイン/adminというapi感があるURLなのにbladeが帰ってくる。
- URLを知ってるとユーザーがアクセスできてしまう。ログインページが表示されるだけでそもそもダサい。

**追加されるエンドポイント**
- api.ドメイン/admin ~

#### 2. nextjs製のリポジトリDを新たに作り管理する

admin.ドメインにNextjsを置き、
api.ドメイン/adminに対しリクエストを行いjsonファイルをNextjsで処理

```php　[web.route]
Route::middleware([])->group(function () {
    Route::prefix('admin')->group(function(){
        Route::get('/', function(){
            return json
        });
    });
});
```

**メリット**
- バックエンドとフロントエンドの書き方が変わらない。 ( 現状と同じようにバックエンドの人はjson返せばいい、フロントエンドはjson受け取ってjsxに流し込むだけでいい )
- なんかかっこいい

**デメリット**
- 他2つに比べてコード量が多い。
- わざわざvercelで管理するほどのものなのか？
- リポジトリが増える。
- URLを知ってるとユーザーがアクセスできてしまう。ログインページが表示されるだけでそもそもダサい。
- admin用のAPIエンドポイントが存在することがバレる

**追加されるエンドポイント**
- api.ドメイン/admin ~
- admin.ドメイン ~

#### 3. Laravel製のリポジトリDを新たに作り管理する

admin.ドメインにLaravelを置き、
リポジトリAと同じDBを共有する(.envのDB_HOST)

```php　[web.route]
Route::middleware([])->group(function () {
    Route::get('/', function(){
        return blade file
    });
});
```

**メリット**
- 管理？保守？は辛いが副作用が少ない？
- 完全にユーザーと分かれてるので分岐処理が減り可読性が高まる。
- ユーザーが操作するようなリッチな機能や操作性も必要ないのでbladeで十分。
- 一番やっすいEC2を用意して使うときだけ起動すれば、安いしセキュリティ○。

**デメリット**
- サービスクラスやリポジトリクラスなどの再実装が必要。 ( 管理者が追加するデータはユーザーは参照しかしないので100％コピペ再実装というわけでもない ) →正直ここ次第な気がする
- リポジトリが増える。
- 若干、他2つよりかはセキュリティが劣る。 ( 攻撃対象が増える ) でもワンチャン高まる

**追加されるエンドポイント**
- admin.ドメイン ~

---

**おそらくこの3パターンになるかと思われますが、どれが一般的な実装なのでしょうか？
もしくは好みでも、理想論でも大丈夫です。**

僕が取りこぼしたメリットとデメリットもあったら教えて欲しいです。

記載されていないパターン4、リポジトリBで管理する app.ドメイン/admin は多分sanctum周りでしんどいのとランディングページが分かれてるので管理者も分けるのが適切だと結論づけ排除しました。

作業者/管理者は僕一人ですが、サービスのスマホアプリ化などに伴って作業者/管理者の追加も発生する可能性があります。( 作業者...エンジニア、管理者...操作する人 )

またlaravelとnextjsは別にruby on railsとnuxtjsとかで置き換えてもらって構いません。

laravel9とnext14 app routerで実装してますが、バージョンとかもどうでも良いです。
実装経験年数は両者3-5年以上はあり実装自体の不安はありません。



管理者サイトのエンドポイントについて

### 実現したいこと
テーブルで、textとfileのいずれかをもつテーブルを作成する場合、
データタイプを区別するための、data_typeのカラムは必要でしょうか？



### 発生している問題・分からないこと
質問の背景

フロントはReactでバックエンドはRailsのでAPIとして実装しています
バックエンドで、textかfileのいずれかを必ず保存するバリデーションを追加したいのですが、

textからfileのどちらともないだけバリデーションエラーを出すだけで、APIの設計的に良いのか
あるいは、data_typeカラムも作成し、フロントからは data_typeとtext or fileをわたした方が良いのか迷っています

ご回答いただけますと幸いです



### 該当のソースコード

```
特になし
```

### 試したこと・調べたこと
- [x] teratailやGoogle等で検索した
- [ ] ソースコードを自分なりに変更した
- [ ] 知人に聞いた
- [ ] その他

##### 上記の詳細・結果
自分的には、data_typeと text かfileの両方を設定した方が良いのでは？と思っています
理由はフロントの制御任せになると思った為です


### 補足
特になし

設計相談