DDD advocates modeling based on the reality of business as relevant to the use cases. It describes the problem areas (business domains) as bounded contexts. Each bounded context contains domain models that represents a particular subdomain of the larger application. Within a bounded context, entities, aggregates, and services are defined and these components become the foundation of the functionalities provided by one microservice. If correctly applying DDD principle in the architecture design, each microservice should be loosely coupled and cohesive.

AppSync accepts various kinds of data sources of the given field in the GraphQL schema. If one bounded context is small enough and can be captured by a DynamoDB table or small sets of tables in Aurora Serverless DB and no complex business logic or restriction is required, a dedicated resolver service may not even be needed. However, this is usually not the common use case in the real world, and custom business logic usually needs to be implemented at a resolver service. In AppSync, the most common way to implement such resolver is either an AWS Lambda function or any other service providing the REST API. AWS Lambda is well suited when the automatic scaling is needed and its computation limitation is also acceptable. Otherwise a REST API service deployed on the server instance running on 24/7 should be considered instead.

Here is an example of an application using AWS AppSync and adopting the DDD design principle. “Streaming Video Metadata System” provides the video metadata including TV programs, movies, celebrity, etc., through the GraphQL API. This can be integrated with an OTT streaming devices’ required search and discover action of OTT video catalogs. The architecture is depicted in the following diagram (Figure 1). Each type of the metadata is identified as a domain (gray box in the diagram), and backed up by the AWS Lambda functions and its own data store. Because every domain may have specific processes and rules, the approach to solve the problem to meet the business requirement can be significantly different. For example, the full-text search of the celebrity data may be used more often by the client side, so Elasticsearch can be a better solution than the RDBMS. For the data that requires more frequent read and write, such as TV channels and programs metadata, DynamoDB would be a better choice.

In the above diagram, the AWS Lambda functions connected to the AWS AppSync are configured to the Direct Lambda Resolver as the data source and responsible for resolving the fields in the GraphQL request. Each of them has the specific business logic to access the underlying database or external REST APIs. Moreover, in this architecture the data of every domain may be ingested by different asynchronous ETL processes. For example, the metadata update can be received on the SQS or dropped as a JSON file on the S3 bucket, or an AWS Lambda Function configured as a scheduled service polling the external APIs provided by the metadata vendor.

Because the AWS AppSync can connect heterogeneous data sources seamlessly but provide a simple GraphQL endpoint, this simplifies the integration of the front-end and building a DDD-oriented back-end architecture substantially. A distributed system with services having clear bounded context also reduces the complexity to plan and manage the infrastructure capacity and optimize service performance based on the data and traffic characteristics of the different domain.

PDG Consulting is a technology and business-focused consulting firm with experience using many of the technologies and concepts touched on above. Regardless of the current state of your technology ecosystem, PDG can help identify pain points and define the roadmap to achieve a cleaner, organized suite of services and applications. And finally, we can help you execute that plan.