Services
Services generally hold data and state around a specific area of concern. The primary responsibility is to receive requests to read or write data, by a variety of transports such as gRPC, SQS, or Kafka.
Orchestrators are generally more suited for containing business logic and complex workflows.
Overview
A single Service is generally responsible for one or more operations around a specific Concept. A Service, and it's Concept, often has a persistent store, such as a Relation Database, with one or more tables related to the Concept.
As an example, an account Concept may hold customer or user accounts, and an account-service provides an API abstraction
over the underlying Relational Database that stores account records, account preferences, etc. The account-service is
responsible for providing the various APIs necessary for Creating, Reading, Updating, and Deleting database tables
pertaining to accounts.
Best Practices
- Services should generally have a focus on a single Concept
- However, Services should generally have two or more persistent objects
- You do not want an architecture with a bunch of services, each containing a single table each
- The Service's persistent store should not be read by any other Service or Application
- Having Services reach into each other's persistent stores is an anti-pattern, and creates tight coupling
- The APIs should be extended as necessary to satisfy new requirements
Qualities
- Contains business data
- Contains less business logic
- Serves as a general-purpose, networked data repository
- Leveraged by one or more Orchestrators or Assessors within their domain