タグ付けされた質問 「service」

3層（DAL、BL、UI）でアプリの構築を開始しました[主にCRM、いくつかの販売レポート、在庫を処理します]。 同僚から、サービスレイヤーパターンに移行する必要があり、開発者が経験からサービスパターンにアクセスするようになったと言われました。彼は、将来そのようにアプリケーションを維持する方がはるかに簡単になるだろうと言いました。 個人的に、私はそれが物事をより複雑にしているだけだと感じており、それを正当化するような利益はあまり見られませんでした。 このアプリには、デスクトップアプリケーションの機能の一部（ただしごくわずか）を使用する小さな部分UIが追加されているため、コードを（あまり多くは）複製していません。いくつかのコードの重複のために、私はそれをサービス指向に変換しませんが、一般的にそれは非常に優れたアーキテクチャであるため、とにかくそれを使用するべきだと言いました。 私はそれでグーグルしようとしましたが、私はまだ混乱しており、何をすべきかを決めることができません。

68 design-patterns  architecture  web-services  services  service 

マイクロサービスアーキテクチャの各サービスには独自のデータベースが必要であることを理解しています。しかし、独自のデータベースを持つということは、実際には、同じデータベースインスタンス内に別のデータベースを単に持つことを意味しますか、それとも文字通り別のデータベースインスタンスを含むことを意味しますか？ これにより、私はデータベースの共有を意味するのではなく、これはノー・ノーであり、むしろデータベースのインスタンスです。 たとえば、AWSを使用していて3つのサービスがある場合、単一のRDSインスタンスで各サービスに3つのデータベースを作成しますか、3つのサービスのそれぞれで独立して使用されるデータベースを含む3つのRDSインスタンスを作成しますか？ 単一のRDSインスタンスで複数のデータベースを使用することをお勧めする場合、次の理由により、独立したサービスを持つという目的を無効にします。 RDSインスタンスのリソースはサービス間で共有されます。特定の時間にデータベースの使用量が多い可能性のあるサービスAは、同じRDSインスタンス上で異なるデータベースを使用するサービスBに影響しますか？ すべてのサービスは、そのRDSインスタンスのデータベースバージョンに依存します。

50 architecture  database  microservices  service 

一部のフレームワークではロジック層が「モデル」と呼ばれるのに対し、一部のフレームワークでは「サービス」と呼ばれるのはなぜですか。それらは互いに異なるのですか、それとも命名規則によってのみ異なるのですか？ 更新1 私が求めている理由は、古典的なMVCフレームワークであるZend Frameworkでは、誰もがモデルの概念を使用しているためです。今、私はAngularJSを学んでいますが、Modelという言葉は消えて、serviceという言葉に置き換えられたようです。 私が気づいたのは、サービスは何度も何度も再利用できるシングルトンに似ていることです（例：RESTクライアント）。一方、モデルはMVCパターンのコントローラーからのデータ操作により関連しています。

15 mvc  model  service 

インタビューで誰かが私に尋ねました：単一のトランザクションで2つのトランザクション/ダオ方法をどのように管理しますか。必要な機能： それらのいずれかが失敗した場合、両方の方法をロールバックする必要があります。 両方のメソッドは、単一のトランザクションで個別に接続して呼び出すことができます。 管理は、サービス層ではなくDAO層で行う必要があります。 私は思う：質問は春のトランザクション管理に関連しています。

12 spring  transaction  service  dao 

私はドメイン駆動設計を約8年間適応してきましたが、これらすべての年が経過した後でも、まだ1つ問題があります。それは、ドメインオブジェクトに対してデータストレージ内の一意のレコードをチェックしています。 2013年9月、Martin Fowlerは、可能であればすべてのドメインオブジェクトに適用する必要があるTellDon'tAsk原則について言及し、操作がどのように行われたかをメッセージで返します（オブジェクト指向の設計では、これはほとんど例外によって行われます）。操作は失敗しました）。 私のプロジェクトは通常多くの部分に分かれており、そのうちの2つはドメイン（ビジネスルールのみを含み、ドメインは完全に永続性を無視する）とサービスです。データをCRUDするために使用されるリポジトリレイヤーを認識するサービス。 オブジェクトに属している属性の一意性はドメイン/ビジネスルールであるため、ドメインモジュールにとっては長くなければならないため、ルールは本来あるべき場所にあります。 レコードの一意性を確認できるようにするには、現在のデータセット（通常はデータベース）にクエリを実行して、別のレコードNameが存在するかどうかを確認する必要があります。 ドメインレイヤーは永続性を無視しており、データを取得する方法がわからないだけでなく、データを操作する方法しか考慮していないため、リポジトリ自体に直接触れることはできません。 私が適応させたデザインは次のようになります。 class ProductRepository { // throws Repository.RecordNotFoundException public Product GetBySKU(string sku); } class ProductCrudService { private ProductRepository pr; public ProductCrudService(ProductRepository repository) { pr = repository; } public void SaveProduct(Domain.Product product) { try { pr.GetBySKU(product.SKU); throw Service.ProductWithSKUAlreadyExistsException("msg"); } catch (Repository.RecordNotFoundException e) { // suppress/log …

10 object-oriented-design  domain-driven-design  service  unique-data