DEV Community: Lalit Kale

Modeling Shared Entities Across Bounded Contexts in Domain-Driven Design

Lalit Kale — Sun, 25 May 2025 14:12:56 +0000

Introduction

When modeling complex systems using Domain-Driven Design (DDD), one of the most common dilemmas architects and engineers face is:

“If two bounded contexts use the same concept — like a Customer — should they share a common model or have separate ones?”

Take, for example, Sales and Support systems within an organization. Both deal with a Customer, but they use that concept differently. So what’s the right way to model this scenario in line with DDD principles?

original context map image courtesy: https://martinfowler.com/bliki/BoundedContext.html

Let’s explore.

Understanding the Problem: Shared Concepts, Divergent Needs

In many organizations:

The Sales team cares about a customer's lead score, purchase intent, and assigned sales rep.
The Support team, on the other hand, is focused on support ticket history, SLA agreements, and incident timelines.

Clearly, while the term "Customer" is shared, its meaning and usage diverge across these contexts. This is a textbook case of polysemy in DDD — the same term having multiple meanings in different bounded contexts.

What Does DDD Recommend?

✅ Model Each Bounded Context Independently

Rather than forcing a single Customer entity to serve multiple masters, DDD encourages modeling the concept according to the specific domain's needs.

This means creating:

SalesCustomer in the Sales context.
SupportCustomer in the Support context.

Each entity will only contain the attributes and behavior relevant to its respective domain. They can be kept in sync using integration events or APIs.

Why Not Share a Single Customer Entity?

Sharing a single customer model across contexts may seem DRY and clean at first, but it introduces tight coupling, cross-team dependencies, and often leads to bloated models full of irrelevant attributes.

Problems with a Shared Model:

Code becomes harder to maintain.
Changes in one context impact others.
The model becomes a compromise that satisfies no one well.

Integration Through Events: The DDD Way

In a properly decoupled system, Sales might publish domain events such as CustomerCreated, CustomerUpdated, or LeadConverted.

Support consumes these events and updates its own SupportCustomer read model.

This keeps the systems loosely coupled and allows each to evolve independently.

Diagram: Visualizing the Pattern

Each bounded context maintains its own Customer model.
Integration events (via Kafka, EventBridge, etc.) keep the models in sync.
The system respects context boundaries and encourages autonomy.

Other Modeling Strategies

In DDD, this scenario can also be approached through different integration patterns depending on organizational and technical constraints:

Pattern	Description
Shared Kernel (discouraged but still valid in rare scenarios)	Shared subset of the model agreed upon and versioned by both teams
Customer-as-a-Service	One context exposes an API or event feed; others consume with translation
Anti-Corruption Layer	Context-specific adapter to isolate internal models from external contracts

Practical Guidelines

Avoid modeling based on database schemas. Model based on domain semantics.
Treat duplication as an acceptable trade-off for autonomy and clarity.
Use ubiquitous language in each context; don’t force uniform terminology.
Synchronize data through events, not shared objects.

Final Thoughts

In Domain-Driven Design, context is king. Just because different domains refer to a Customer doesn’t mean they are talking about the same concept. Forcing a unified model creates fragility and limits agility.

Instead, embrace duplication, model explicitly, and integrate intentionally. That’s how you build robust, evolvable systems.

#aws #eventdrivenarchitectures #eda

Lalit Kale — Tue, 01 Apr 2025 04:38:47 +0000

Lalit Kale for AWS Community Builders

Mar 24 '25

A Socio-Technical Maturity Model for Large-Scale Event-Driven Architectural Systems

#eventdriven #aws #organizationalpatterns

Comments

4 min read

A Socio-Technical Maturity Model for Large-Scale Event-Driven Architectural Systems

Lalit Kale — Mon, 24 Mar 2025 17:39:05 +0000

In modern enterprises like Amazon, Netflix, and JD.com, success hinges on building scalable, decoupled, and resilient systems. Event-Driven Architecture (EDA) paired with Domain-Driven Design (DDD) is no longer just a pattern—it's the architectural backbone of modern digital platforms. But EDA adoption is not just technical; it’s a socio-technical transformation.

This guide introduces a comprehensive EDA Maturity Model for enterprise-scale systems, including engineering roles, DDD alignment, team evolution, and hiring strategies. It is structured to be useful for engineering managers, principal engineers, and staff engineers who are driving the adoption of EDA within large global teams.

📊 The 4A EDA Maturity Model: "Awaken, Align, Amplify, Automate"

Transitioning to an Event-Driven Architecture is not a one-time event; it’s a journey that unfolds in stages.

To simplify this transformation, we have developed the 4A Model, representing four progressive stages: Awaken, Align, Amplify, and Automate. Each stage addresses the evolving needs and capabilities of teams, helping them move from basic awareness to fully automated, AI-driven systems.

1.🔥 Awaken — Reactive & Exploratory

In the Awaken stage, teams are just starting their journey with EDA. They might still be predominantly API-centric, with little awareness of event-driven patterns. This stage is characterized by experimentation and a lack of standardized practices.

Key Focus: Building awareness and creating foundational event-driven workflows. Teams should begin with EventStorming workshops to map out business events and domain boundaries. At this stage, it's essential to adopt structured logging practices, using identifiers like logLevel: EVENT, correlationId, and traceId to make event logs easily traceable.

Best Practices:

Start EventStorming workshops to identify key domain events.
Use structured logging to ensure event traceability and consistency.
Build a simple EDA flow using SNS and Lambda to demonstrate basic event processing.

Common Pitfalls: Teams often mistake commands for events or treat event processing as synchronous. Educate teams on the difference between commands (requests to perform an action) and events (facts of something that has happened).

2.🌍 Align — Standardized & Stable

In the Align stage, teams start treating events as first-class citizens. There is a conscious effort to standardize schemas, enable observability, and ensure fault tolerance through dead-letter queues (DLQs) and retries.

Key Focus: Establishing consistency and operational stability. Teams should develop a schema registry and enforce idempotency strategies for event processing. Monitoring and observability practices should be robust, allowing teams to detect and troubleshoot failures efficiently.

Best Practices:

Use AWS EventBridge Schema Registry to standardize event definitions.
Enable DLQs to handle unprocessed or failed messages.
Implement distributed tracing with AWS X-Ray and OpenTelemetry for complete event visibility.

Common Pitfalls: Engineers may overlook the need for idempotency, leading to duplicate processing. Implement clear guidelines on ensuring idempotent event consumers.

3.🚀 Amplify — Scalable, Global & Performant

As EDA adoption matures, the focus shifts to scalability and global distribution. Teams build resilient, multi-region systems with optimized performance for high-traffic scenarios.

Key Focus: Implementing multi-region routing and ensuring the system can handle high-volume event traffic efficiently. Teams should differentiate between real-time and batch processing to optimize resource use.

Best Practices:

Use EventBridge Global Endpoints to route events based on latency or regional availability.
Implement multi-tiered event processing with Kinesis for real-time data and SQS for asynchronous tasks.
Automate failure recovery and cost optimization using DLQs and Lambda tuning.

Common Pitfalls: Teams may struggle with global consistency and latency. Prioritize regional processing for latency-sensitive events.

4.🤖 Automate — AI-Driven & Self-Healing

In the final stage, the EDA system is fully automated and capable of self-optimization. AI-driven monitoring and predictive scaling ensure the system adapts to changing conditions without manual intervention.

Key Focus: Enabling AI-based anomaly detection, predictive scaling, and autonomous recovery. The goal is to build a self-healing architecture that requires minimal human oversight.

Best Practices:

Train AI models with AWS SageMaker to detect anomalies in event patterns.
Use AWS Systems Manager to automate incident response.
Implement event-driven FinOps to optimize operational costs continuously.

Common Pitfalls: Over-reliance on automation without proper monitoring can lead to undetected issues. Balance AI-driven responses with human oversight when necessary.

🌟 Hiring Practices and Skills for EDA Adoption

Hiring engineers who can adapt to the 4A Model requires a clear understanding of the skills needed at each stage. Here’s how to hire and build teams for each phase:

Awaken Stage: Look for engineers with a basic understanding of microservices and asynchronous programming. Ideal candidates have worked with REST APIs and have an interest in event-driven patterns.
Align Stage: Seek candidates with experience in message brokers (e.g., SNS, Kafka) and schema management. They should understand idempotency and distributed tracing.
Amplify Stage: Focus on engineers who have managed multi-region systems and have experience in performance tuning. Skills in AWS EventBridge, Lambda optimization, and global traffic management are key.
Automate Stage: Hire engineers with experience in AI/ML integration for anomaly detection. They should be familiar with AWS SageMaker and how to implement self-healing workflows.

Interview Tips:

Ask about their experience with event-driven failures and recovery.
Pose scenarios involving multi-region event consistency.
Challenge them to design an autonomous EDA system that can self-heal.

🌟 Conclusion

Mastering Event-Driven Architecture in large enterprises requires more than technical proficiency. It demands a cultural shift in how teams think about events, data flow, and system autonomy. By following the 4A Maturity Model—Awaken, Align, Amplify, Automate—teams can progressively enhance their capabilities, leading to scalable, resilient, and self-healing systems.

By fostering the right mindset, equipping teams with the proper tools, and hiring engineers who understand EDA and DDD principles, organizations can transform their architectures to meet modern demands. Embrace the journey, build iteratively, and let your events do the talking.

Ready to elevate your EDA strategy? Let’s make the transition together!

Setup business metrics with Amazon CloudWatch and AWS Lambda at lower cost

Lalit Kale — Fri, 28 Oct 2022 13:01:39 +0000

Any good business runs with goals and key performance indicators (KPIs) that are monitored and managed. These can be user signups, or Subscriptions sale trend, or customer churn. Any Cloud-born or cloud-native business is no exception to this.

This post provides how to guide for creating business metrics using Amazon CloudWatch and AWS Lambda services.

Readers, familiar with EMF format for CloudWatch, can jump to the Implementation section.

Introduction

Before we dive deeper, let's have a tweet size introduction to AWS CloudWatch and AWS Lambda service.

Amazon CloudWatch helps to observe and monitor AWS resources and applications in the cloud and on premises.

AWS Lambda is a serverless, event-driven compute service that lets you run code for any type of application or backend service without provisioning or managing servers. AWS Lambda helps to focus on delivering customer value.

Any AWS service publish metrics in Amazon CloudWatch. Amazon CloudWatch can also publish your own application specific metrics. These metrics are called as custom metrics. The number of third-party API calls, or the count of status codes returned by an API, etc are a few examples. Based on these metrics, you can build your own dashboards or alert notifications etc.

Ways to add Amazon CloudWatch custom metrics

PutMetricData API

Amazon CloudWatch provides an API through which you can put the custom metrics. But, sending the API request is a synchronous process. For high-volume applications, you have to batch up the requests for CloudWatch API – "PutMetricData" API. Otherwise, your requests will be throttled by CloudWatch API. CloudWatch API usage for adding custom metrics also incurs cost.

Metric Log Filters

Metric log filters are another way to create CloudWatch custom metrics. The Metric log filters can search and filter data points needed to create metrics from CloudWatch log groups. It's a better option as compared to using CloudWatch API since it's asynchronous. The drawback of this method is, every time you need to create a new metric, you have to create the metric log filters.

EMF For CloudWatch

A third option is using Amazon CloudWatch specification for Embedded Metric Format (EMF). It's again an asynchronous way to create custom metrics. But with EMF format, there are no incurring charges for customer. There are no prerequisites as previous method of log filters.

Implementation

This walkthrough assumes familiarity with AWS Lambda and AWS CloudWatch services. It also assumes that you can deploy AWS lambda in your own AWS account.

The implementation uses AWS Lambda and Amazon CloudWatch. But, you can use Amazon CloudWatch EMF format with any other AWS compute services such as Amazon ECS, Amazon EKS and AWS Fargate.

Let's create AWS Lambda function to log custom metrics. In our example, below, the lambda function orderservice represents a fictitious order service. In this service, we would be creating metrics for average order value amount trend.

For order service lambda function, first create a directory and initialize npm.

 mkdir orderservice && cd orderservice && npm init -y

Now, install aws-embedded-metrics library in the orderservice project directory. aws-embedded-metrics library handles logging custom metrics in Amazon CloudWatch EMF format.

  npm install aws-embedded-metrics

This will create a node_modules directory with the required dependencies.

Once you have installed the dependencies, create a new file in the project directory and name it index.js. In index.js, export the function as shown below.

const { metricScope } = require("aws-embedded-metrics");

const orderMetrics = metricScope(metrics =>
  async () => {
    // ...
  });

exports.handler = orderMetrics;

Now, within the function, you have to create your own metric namespace and select the dimensions for the metrics. For high cardinality values, you can use property rather than dimensions. So, complete orderMetrics function is as follows


const { metricScope } = require('aws-embedded-metrics');

const orderMetrics = metricScope(metrics => async event => {
  //define the namespace for custom metrics 
  metrics.setNamespace('OrderManagement');

  //set the dimentions 
  metrics.putDimensions({ Service: 'OrderService', CustomerId:'26102022' });

  // write the metric value to cloudwatch
  metrics.putMetric('Avg. Order Value',Math.floor(Math.random() * 100) , 'None');

  // add context as properties to build cloudwatch log insights queries
  metrics.setProperty('AccountId', '123456789012');
  metrics.setProperty('RequestId','45b7d3b0-ca99-44a2-93ad-05e29c9d40e6');
  metrics.setProperty('OrderId', '7b125931-7898-4eab-bf16-78b8dc87707d');
  metrics.setProperty('Payload', {
    sampleTime: new Date(),
    customerId: 26102022,
  });

});

exports.handler = orderMetrics;

Note that, putMetric parameter value is randomly generated for demo purposes. You have to replace it with your own metric value.

Now, you need to compress all the files in the project directory and upload the ZIP file to Lambda console.

zip -r ../orderservice.zip .

After uploading the orderservice.zip to lambda function, you can test the lambda with test event. Since, we have randomized the putMetric input value, we are expected to see the logs having the custom metric. There can be a couple of seconds of lag for reflecting values in Amazon CloudWatch metrics page and dashboard.
To simulate real world traffic, you have to invoke orderservice lambda several times. You can use lambda function's Test feature with sample event to simulate invocations.
Now, you will see the ordermanagement metric as shown below under CloudWatch Metrics.

Clicking on the OrderManagement metric, you can see CustomerId,Service,ServiceType and ServiceName metric. After small touch ups on the graph, the final output of custom metric looks as below.

You can consider this business metric of Avg. Order Value as any other Amazon CloudWatch metric. Furthermore, you can create CloudWatch alerts based on CloudWatch custom metrics, for example – set up an alert when we receive an order of more than USD 50 million etc.

The same business metrics can be utilized to create CloudWatch dashboards to better serve your customers.

In summary, EMF format for Amazon CloudWatch is a great feature which can be utilized for creating the custom business metrics. Many customers have enjoyed up to 65% of cost reduction with using EMF format for Amazon CloudWatch, among other benefits. What you are waiting for? Now Go Build!

AWS Architecture Diagrams Guidelines

Lalit Kale — Tue, 25 Oct 2022 15:02:06 +0000

AWS Architectural diagrams represents AWS resources and other significant objects and their relationships. AWS architectural diagrams communicate the exact blueprints of the solutions. Yet, many engineers and architects struggle to produce good diagrams. You will find many diagrams, over the internet, which do not represent the meaningful context.

This article provides guidelines on how to draw the architectural diagrams. These guidelines came from my own experience and many in the AWS community.

Need for Architectural Diagrams

On the surface, it may look simple to doodle a couple of boxes and arrows. But, it is critical activity from the system point of view. So, let's explore why architectural diagrams is even part of the skill set of any good architect.

Conceptual integrity is one of the key factor for successful architecture. It is the quality of a system where all the concepts and their relationships with each other are consistently applied throughout the system. Even if many people work on the system, it would seem cohesive and consistent, as if only one mind was guiding the work.

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. — Frederick Brooks, The Mythical Man-Month: Essays on Software Engineering

Many great technical people are not known for their communication skills. This simple fact hampers the communication of vision. Time is another big factor, due to which conceptual integrity faints away. This signifies the importance of having and maintaining the architectural diagrams.

Formal Architectural Documentation Models

There is a no consensus on one single way or method in the wider software architecture community. But, there are some well-known software architecture documentation models exists. We will explore two of such models in this section.

C4 Model
Simon Brown came up with the C4 model. C4 model visualizes the architecture into a set of Context, Containers, Components, and Code. The C4 model comes with a recommended set of symbols indicating context, containers, components, and code. C4 model also encourages using a lot of text into the diagrams.
I have not used C4 model myself, so could not comment much on it.
I am not sure if C4 model may be enough to describe the whole cloud based architecture – which can meet all stakeholders. So, please do share your AWS architecture diagrams or ways with which you have used C4 model to describe the AWS architectures. This way, I and larger community can gain insights into C4 models and also use it.

4+1 Views
Philippe Kruchten has described 4+1 views in his IEEE article. The views represent the system from the different stakeholders' standpoint. The four views of the model are logical, development, process and physical view. Each view is represented by different types of UML diagrams.

I have been practising 4+1 views from long time. I also have few guidelines for depicting a logical view. Logical view should remain agnostic to any cloud provider or specific technology stack.

I use the official AWS icon set to depict deployment view. AWS has published the official icon set to build architectural diagrams. Its use bring consistency among the different AWS cloud practitioners and users. You can explore the above link and see that the icon set is also made available for many diagramming tools.

Logical View Diagrams Guidelines:

Develop your mental model of the solution before making any drawings. Without having a mental model, you will fail to draw any diagram.
Always think about maintaining conceptual integrity as solution architect. Does the system look like cohesive enough to serve its purpose? Does the system subcomponents are having single purpose of existence? These are some questions can help you to keep check on conceptual integrity.
Use consistent shape and forms to communicate different subsystems and components.
You may find C4 model useful to depict the logical view.
Use simple shapes to depict components across the system. Do not mix vendor specific symbols to represent the logical view. e.g. using of AWS icons to represent components in logical view diagrams.

Physical View Diagrams Guidelines (AWS Architectural Diagrams Guidelines):

Network diagrams and deployment diagrams are like actual builds. You can test them before actually building the real infrastructure. It is a simple but effective method of testing your infrastructure. Data flows or packet flows traceability makes these diagrams a very valuable asset.
Consistency in diagrams is key characteristics of a great diagram. e.g. Do not represent EC2 instance, with two different icons. Use the latest official AWS diagramming icon set. There has been three iterations of the icon sets. So if you select one version, please use it without mixing other version icon set symbols.
Depict one or most two flows into one single diagram. Do not try to showcase every flow and every resource in one single diagram.
AWS reference architectural diagrams reference architecture diagrams are one-pagers for conversations and having something handy. Your intention and usage purpose may vary, so do not copy these style of diagramming all the time.
Put the title of the diagram on top. The title should be communicating the system and the diagram's purpose or intent.
Depict the AWS account boundary, even if your solution has a single AWS account. For multi-account scenarios, show only participating accounts of the system or subsystem. In such cases, it is better to prepare a separate multi-account diagram.
Make sure the diagrams are representing global, regional and zonal AWS services as per their scopes. e.g. S3 is a global service, so it should live inside account but not within VPC. VPC is regional service, hence it should live in a region.
Avoid too many lines to represent each relationship or data flow between resources. In such cases, apply different strategy, e.g. representing lines with different colors or not drawing the connections or skipping the connection itself. e.g. blue line represents the traffic flowing from US-East-1 region and red line represents traffic flowing from EU-West-1 region.
Do use standard conventions that are set by AWS or used in community. But, do not assume, everyone is aware of such conventions. e.g. private subnets shown with blue background and Public subnets in VPC are always depicted with green background.
Architectural diagrams are part of the knowledge base of your organization. It has long-lasting value. Architectural diagrams can lose value, if implementation varies over the period of time. So, please ensure period review and invest time in maintaining the architectural diagrams.
At least there should be one diagram representing the exact systems' production environment. If you work with development or test or other more environments, you can also have the diagrams representing them, but it is not necessary.
Please do check the arrow directions that your flow is depicting.
Show return traffic with intermittent arrows.
Show logical grouping, e.g. group of lambdas representing services with a box with intermittent lines.
Always do peer-review of system architecture and the diagrams. Make sure, your peers can understand and interpret the diagrams. If your peers have to ask a lot of questions or you need to describe some part of the system more, then you may think to revisit the diagrams.

I am looking forward to enhancing this post and publish update based on the feedback I receive. So, feel free to share your views in comments.

References:

https://www.infoq.com/articles/crafting-architectural-diagrams/
The Mythical Man-Month: Essays on Software Engineering, Frederick Brooks