Karthick's Sunday Learning (08/12)

As I strive to learn every day, here are my this week's learning and deep reading as I took some time to recap/reflect on those topics for my network and newsletter. Are you motivated to learn more every day? If not, ask yourself what is missing and go after it.

1. Domain Driven Design - Introduction

2. Circuit Breaker Pattern

Domain Driven Design - Introduction

Domain-Driven Design (DDD) is a software development philosophy that emphasises the importance of understanding and modelling the business domain. It is a strategy aimed at improving the quality of software by aligning it more closely with the business needs it serves.

Primary goal of DDD is to emphasise collaboration between technical experts and domain experts to create systems that accurately reflect the core business concepts and operations. The over all goal of DDD is to ensure that the software solution is aligned with the business needs and provides real value.

Imagine you are building a big LEGO castle. To make sure the castle is strong and looks amazing, you need to follow some steps and use the right LEGO pieces. Domain-Driven Design (DDD) is like those steps, but for making computer programs.

DDD helps make sure that everyone building the computer program has the same idea of what it should do. It’s like making sure all your friends know where to put the LEGO bricks when you're building the castle together.

What is a Domain?

In the context of DDD, a domain refers to the specific area of knowledge or activity that the software is intended to address. For instance, if you are developing software for a healthcare system, the domain would include all the concepts related to healthcare, such as patients, treatments, appointments, and medical records.

Experts who are well-versed in a specific industry are known as Domain Experts - such as someone one into Leather products, Hospitality, Fleet service management etc. In the context of DDD taking an Insurance industry as an example, experts can best know about Customer, Policy, Claims, Security and Documentation domains who have the deeper knowledge of that domain which is critical for understanding the Domain in question.

How does DDD work

Sticking with your LEGO example...

1. Understanding the Domain: This is like learning about the kingdom where your LEGO castle will be. You need to know all about the people, places, and things in that kingdom. In DDD, the "domain" is the area of knowledge or activity your program is about.

2. Talking to Experts: Just like you might ask someone who knows a lot about castles for advice, in DDD, people building the program talk to experts who know a lot about the problem the program is trying to solve.

3. Using a Common Language: When you and your friends build the LEGO castle, you all agree on what to call the different parts, like towers, walls, and gates. In DDD, everyone agrees on the terms they use so there’s no confusion.

4. Designing the Program: This is like drawing a plan for your LEGO castle. You figure out how all the pieces fit together. In DDD, you design how the different parts of the program will work together.

5. Building the Program: Finally, you put all the LEGO pieces together to build the castle. In DDD, developers write the code to build the program based on the design.

Why is DDD important?

DDD is important because it helps bridge the gap between the business and technical sides of a project. By focusing on the domain, developers and domain experts can work together to model the business processes and rules correctly. This ensures that the software is not only technically sound but also meets the actual needs of the users.

Core concepts of DDD

1. Ubiquitous Language

One of the key principles of DDD is the creation of a ubiquitous language. This is a common language used by both developers and domain experts to discuss the domain. It ensures that everyone is on the same page and reduces misunderstandings. For example, if the term "appointment" is used, everyone should have a clear and consistent understanding of what it means in the context of the system.

2. Entities

Entities are objects that have a distinct identity that runs through time. In other words, entities are things that have a unique identifier. For example, in a healthcare system, a "Patient" would be an entity because each patient has a unique identifier, such as a patient ID.

3. Value Objects

Value objects are objects that describe some characteristics or attributes but do not have a distinct identity. They are typically used to define aspects of entities. For instance, an "Address" in a healthcare system would be a value object. Different patients can have the same address, but the address itself does not have a unique identity.

4. Aggregates

Aggregates are clusters of entities and value objects that are treated as a single unit. The aggregate is defined by a root entity, known as the aggregate root, which is responsible for ensuring the integrity of the aggregate. For example, in a healthcare system, a "Medical Record" might be an aggregate that includes entities like "Patient" and value objects like "Treatment".

5. Repositories

Repositories are used to encapsulate the logic needed to access data sources. They provide a way to retrieve and store aggregates. For example, a "PatientRepository" would handle the retrieval and storage of patient entities from the database.

6. Services

Services are operations or actions that do not naturally fit within an entity or value object. They represent business logic that is not tied to a specific entity. For example, a "SchedulingService" might handle the logic for scheduling appointments.

7. Factories

Factories are responsible for creating complex objects or aggregates. They encapsulate the creation logic that might be too complex to handle within the entities themselves. For instance, a "MedicalRecordFactory" might be responsible for creating a new medical record with all the necessary entities and value objects.

Implementing DDD

Implementing DDD involves several steps to ensure that the software accurately reflects the domain:

1. Collaboration

Effective collaboration between developers and domain experts is crucial. Regular meetings and discussions are necessary to ensure that the domain concepts are well understood and accurately represented in the software.

2. Modeling

Creating models that represent the domain is an essential part of DDD. These models are often represented as diagrams or code that outline the entities, value objects, aggregates, and their relationships.

3. Iteration

DDD is an iterative process. As the understanding of the domain evolves, the models and code should be continuously refined and improved. This iterative approach ensures that the software remains aligned with the business needs.

Benefits of DDD

1. Improved Communication

The use of a ubiquitous language and close collaboration between developers and domain experts improves communication and ensures that everyone has a shared understanding of the domain.

2. Alignment with Business Goals

DDD ensures that the software is closely aligned with the business goals and needs. This alignment leads to solutions that provide real value to the users and stakeholders.

3. Flexibility and Adaptability

By focusing on the domain, DDD creates software that is more flexible and adaptable to changes in the business environment. As the business evolves, the software can be more easily modified to accommodate new requirements.

Challenges of DDD

1. Complexity

DDD can introduce additional complexity into the development process. Creating detailed models and maintaining a ubiquitous language requires effort and discipline.

2. Learning Curve

There is a learning curve associated with DDD. Both developers and domain experts need to understand the principles and practices of DDD to effectively implement it.

3. Collaboration

Effective collaboration between developers and domain experts is essential for DDD. This collaboration can be challenging to achieve, especially in large or distributed teams.

Domain-driven design is a powerful approach to software development that emphasizes collaboration and alignment between technical and business experts. By focusing on the domain, DDD ensures that the software accurately reflects the business needs and provides real value to the users. Although it introduces some complexity and requires a strong commitment to collaboration, the benefits of improved communication, alignment with business goals, and flexibility make DDD a valuable approach for many projects.

Circuit Breaker Pattern

In this edition, keeping with the Microservices learning theme, we are going to learn about one of the Design patterns for Microservices within the Cross-cutting concern pattern category called Circuit Breaker pattern.

Although microservices aim to allow applications to operate independently, there can still be issues with cross-cutting concerns. Microservice design patterns like blue-green deployment, the circuit breaker pattern, and service discovery can help mitigate these concerns.

In the realm of software architecture, especially in microservices and distributed systems, resilience and reliability are paramount. The Circuit Breaker Pattern emerges as a critical tool for achieving these goals, enabling systems to withstand and recover from failures gracefully. This pattern, inspired by electrical circuit breakers, is designed to prevent the cascade of failures and ensure that systems can continue to function even in the face of disruptions.

Imagine you love playing with your toy robot, and you control it with a remote. Now, think about what would happen if every time you pressed the forward button, the robot's battery started overheating. To protect the robot from breaking, you might stop pressing the button until the robot cools down. This way, you keep your toy safe and can continue playing with it later without any damage.

At its core, the Circuit Breaker Pattern is akin to its electrical counterpart. In electrical circuits, a breaker stops the flow of current in case of an overload or short circuit, preventing damage to the system. Similarly, in software, a circuit breaker halts the flow of requests to a service that is experiencing failures, thereby preventing further damage and allowing the system to recover.

Components of Circuit Breaker Pattern

The Circuit Breaker Pattern comprises three primary states:

• Closed: In this state, the circuit breaker allows requests to flow through as usual. If the requests are successful, the system continues to operate normally. However, if failures occur, the circuit breaker keeps track of the failure count.

• Open: When the failure count exceeds a predefined threshold, the circuit breaker transitions to the open state. In this state, all requests to the service are immediately blocked, and an error is returned. This helps to prevent the system from being overwhelmed by failing requests.

• Half-Open: After a specified timeout period, the circuit breaker moves to the half-open state. In this state, a limited number of requests are allowed to pass through to test if the service has recovered. If these requests succeed, the circuit breaker transitions back to the closed state. If they fail, it returns to the open state.

Implementing Circuit Breaker Pattern

Implementing the Circuit Breaker Pattern involves defining the thresholds and timeout periods for transitioning between states.

This can be done through configuration settings or code. Various libraries and frameworks, such as Netflix Hystrix (no longer maintained), Resilience4j, and Polly, provide pre-built implementations of the Circuit Breaker Pattern, making it easier to integrate into your system.

Benefits of the Circuit Breaker Pattern

The Circuit Breaker Pattern offers several key benefits:

• Improved Resilience: By halting requests to failing services, the pattern helps to prevent the entire system from being affected by localised failures.

• Faster Recovery: The pattern allows services to recover without being overwhelmed by a flood of failing requests.

• Enhanced Stability: It provides a mechanism for gracefully handling failures, leading to a more stable system overall.

• Resource Protection: By stopping requests to failing services, it helps to conserve valuable system resources.

Challenges and Considerations

While the Circuit Breaker Pattern is highly effective, it does come with some challenges and considerations:

• Configuration Complexity: Properly setting thresholds and timeout periods requires a deep understanding of your system's behaviour and load patterns.

• Partial Failures: The pattern is effective for complete service failures, but may require additional handling for partial or intermittent failures.

• Fallback Strategies: It's important to design appropriate fallback strategies for when the circuit breaker is open, ensuring that users still receive a meaningful response.

• Monitoring and Logging: Effective monitoring and logging are essential to understand when and why circuit breakers are triggered and to adjust configurations as needed.

Use Cases and Real-World Applications

The Circuit Breaker Pattern is widely used in various industries and applications:

• Microservices Architecture: In microservices-based systems, where services often depend on each other, the pattern helps to isolate failures and maintain overall system stability.

• Cloud-Based Services: Cloud environments, with their dynamic and sometimes unpredictable behavior, benefit greatly from the resilience provided by circuit breakers.

• API Gateways: API gateways can use the Circuit Breaker Pattern to manage downstream service failures and provide consistent responses to clients.

• E-commerce Platforms: High-traffic platforms, such as online stores, use circuit breakers to ensure that key services remain available even during peak loads or service failures.

Resources

• Circuit breaker in Microservices - An intro - https://www.youtube.com/watch?v=HRS9mIfiNn4

• Circuit breaker design pattern with example:

* https://digitalvarys.com/what-is-circuit-breaker-design-pattern/

* https://microservices.io/patterns/reliability/circuit-breaker.html

The Circuit Breaker Pattern is an indispensable tool for building resilient and reliable distributed systems.

• By stopping the flow of requests to failing services, it prevents cascading failures, ensures faster recovery, and enhances overall system stability.

• While implementation requires careful consideration and monitoring, the benefits far outweigh the challenges.

• As systems grow in complexity, the Circuit Breaker Pattern will continue to play a vital role in maintaining the health and resilience of modern software architectures.

What are you learning? May be we can learn together!

Happy learning!