This is part II of my previous post on System Design methodologies. In the previous post we discussed Monolithic, Microservice and Service Oriented architectures. Today we will learn about Domain Driven Design(DDD), Event-Driven Architecture (EDA) and Serverless architectures.
Domain-Driven Design (DDD): Domain-Driven Design (DDD) creates software that mirrors business requirements precisely. It's like creating a map of the business world, and then using that map to build the software.
DDD helps make sure that everyone is involved in building the software. The developers, stakeholders, and field experts all know what the software needs to do. This way, the software can be built to meet the real needs of the business, and not just what someone thinks it should do.
Pros:
DDD emphasizes on understanding the business domain.
It promotes creating modular software. The software is easy to maintain and adapt to business changes.
It also encourages using aggregates to boost scalability and performance. They do so by cutting database queries and improving data consistency.
Cons:
DDD has a steep learning curve for developers. It takes a lot of time and effort to learn and use its principles.
It can lead to a complex software system, particularly if not implemented correctly
Implementing DDD can be expensive at first. It includes training, consulting, and development time. This may not be possible for all organizations.
Event-Driven Architecture (EDA): EDA is a framework that processes events and reacts to changes in a system. It does it asynchronously. In EDA, an event occurs when something happens or is about to happen. The event triggers a reaction in the system. Follow these steps to implement EDA.
Identify the events that will trigger reactions in your system.
Design the event handlers that will react to the identified events.
Create an event bus that enables publishing and subscribing to events.
Implement an event store that stores all the events that have occurred in the system.
Test and debug your EDA system to ensure it works as expected.
Pros:
EDA enables real time processing of events which helps in immediate processing
It is easy to scale horizontally, more event handlers can be added into the system easily
EDA is loosely coiled which makes it easy to modify and scale.
Cons:
EDA can introduce complexity particularly when there are multiple event producers.
Debugging and testing are hard because the architecture is asynchronous.
EDA systems can have issues with event versioning. Changes to event structure can break compatibility with existing handlers.
Serverless Architecture: Serverless architecture is a cloud computing model. In it, the cloud provider manages the infrastructure. The developer only writes and runs code. The term "serverless" doesn't mean no servers exist. Instead, it means the developer doesn't need to provision or manage servers.
In serverless architecture, the application is broken into small, separate functions. They can be run on demand. Programmers usually write these functions in a language like Node.js, Python, or Go. They deploy them to a cloud platform such as AWS Lambda, Google Cloud Functions, or Azure Functions.
When a user makes a request, the cloud platform automatically provisions the resources. These resources include servers to run the function. The function is executed, and the result is returned to the user. Once the function has finished, it releases the resources. The developer only pays for the time and resources used while the function ran.
Pros:
Pay only for the time and resources used during the execution of the function. It become a cost-effective option.
Serverless architectures can scale automatically to handle changes in traffic.
Serverless architectures can be highly available. The cloud provider manages the infrastructure and ensures the application is always available.
Cons:
The first time a function is executed, it may take longer to start up, which can lead to slower response times.
You may become locked into a specific cloud provider's ecosystem. It makes it difficult to move to another provider.
Debugging and testing serverless applications can be challenging. Because the developer doesn't have direct access to the underlying infrastructure.
Top comments (0)