Architectural Rules of Thumb

There are number of architecture rules

1.The Seperation of Concerns

Separation of concerns is a design principle that suggests breaking down a software system into
smaller, more manageable components, with each component focused on a specific task or
responsibility.
This separation helps to reduce complexity, improve maintainability, and enhance reusability.

In software development, concerns can be categorized into different areas, such as business logic, data
persistence, user interface, security, and performance.

Separating these concerns into different components allows developers to work on each component
independently, without affecting the other parts of the system

For example, in a web application, the user interface can be separated from the business logic,
allowing developers to focus on the presentation layer without affecting the core functionality of the
application.
Similarly, the data persistence layer can be separated from the business logic, allowing developers to
work on the storage and retrieval of data without affecting how the data is used within the application.
By separating concerns, developers can write cleaner, more modular code that is easier to maintain, test,
and reuse.

This design principle is used in many software development methodologies, such as Model-View-Controller
(MVC), Service-Oriented Architecture (SOA), and Microservices Architecture.

2.principle of cohesion
The principle of cohesion refers to the degree to which the elements within a single
module or component of a system work together to achieve a single, well-defined
purpose.

In software engineering, this principle is often used to guide the design and
organization of code.

Cohesion can be used as a measure of how strongly related the functions in a module
are.
It is desirable to have strong cohesion in a module.
3.Coupling

Coupling refers to the degree of interdependence between different modules or

Microservices are a software architecture approach that involves breaking down a complex application into small,
independently deployable services.

Each service performs a specific function and communicates with other services through a lightweight, often RESTful-API.

Microservices are designed to be loosely coupled, meaning that changes to one service should not affect other services.
This makes it easier to update and maintain an application, as developers can make changes to a single service without
impacting the entire application.

Microservices are typically deployed in containers, such as Docker, and managed by an orchestration tool, such as
Kubernetes. This allows for easy scaling and management of the individual services.

There are several benefits to using microservices,

1.Scalability
2.Flexibility
3. Resilience
4.Team autonomy
1.Scalability: Microservices can be scaled independently, allowing for more efficient use of resources and faster
response times.

2.Flexibility: Services can be developed and deployed independently, making it easier to adopt new
technologies and respond to changing business needs.

3.Resilience: If one service fails, it does not necessarily affect the entire application, improving the overall
resilience and availability of the system.

4.Team autonomy: Each service can be developed and maintained by a separate team, allowing for greater
autonomy and faster development cycles.

However, there are also some challenges associated with microservices, such as increased complexity in
managing a distributed system and ensuring the consistency of data across services. It is important to carefully
consider the tradeoffs and design a microservices architecture that is well-suited to the specific needs of the
application.
Micro services and data tier
Microservices is an architectural approach to building applications that involves breaking down an application into smaller,
independent services that can be developed, deployed, and scaled separately.

Each microservice typically has its own database, which is responsible for storing and managing its data. This approach
allows for greater flexibility and scalability, as well as easier maintenance and updates.

The data tier, or database layer, is a critical component of any application, including those built using a microservices
architecture.

In a microservices architecture, each microservice typically has its own database, which can be either a traditional
relational database or a NoSQL database.

This approach allows each microservice to have its own data store that can be optimized for its specific needs and
requirements.
However, this approach also presents some challenges. For example, if multiple microservices need to access the same
data, it can lead to data inconsistencies and synchronization issues.
To address these challenges, various patterns and techniques have been developed, such as using event-driven
architectures, data replication, and data caching.
Additionally, it's important to carefully plan and design the data tier to ensure it meets the scalability, availability, and
performance requirements of the application as a whole.
Devops architecture and resilience
DevOps architecture is a methodology that aims to improve collaboration and communication between
development and operations teams.

It is a combination of software development and IT operations that emphasizes the automation and
monitoring of all steps in the software delivery process.

Resilience is an important aspect of DevOps architecture because it ensures that systems can recover
quickly from failures or disruptions.

To build a resilient DevOps architecture, there are several key principles that must be followed:

Automation: Automating the software delivery process can help reduce errors and increase reliability.
Automated testing, deployment, and monitoring can help identify and address issues before they become
major problems.

Continuous integration and delivery: Continuous integration and delivery (CI/CD) pipelines can help ensure
that code changes are thoroughly tested and integrated into the software system as quickly as possible. This
can reduce the risk of errors and make it easier to recover from failures.
Monitoring and logging: Real-time monitoring and logging can help identify issues as they arise, allowing teams to
respond quickly and efficiently. Monitoring can also help identify patterns of failure that can be used to improve the
system over time.

Fault tolerance: Building fault-tolerant systems means that they can continue to operate even when one or more
components fail. This can be achieved through redundancy, backups, and failover mechanisms.

Disaster recovery: In the event of a major disruption, a disaster recovery plan can help ensure that systems can be
quickly restored. This plan should include backups, data replication, and failover mechanisms.

By following these principles, DevOps teams can build resilient architectures that can withstand disruptions and
failures. This can help ensure that systems are always available and performing at their best, even in the face of
unexpected challenges.