Introduction To Micro-Services Design Patterns

• Business domain centric/Single concern: With application of DDD, as We will mention in the next secti

• SRP: Design for Single Responsibility : Each micro-service has its own responsibility, with no intersection with other one, which increases modularity, and single point of development and maintenance

• API-First Design

• API versioning

• Use Asynchronous Communication When Possible

• 9. Use an API Gateway

• 10. Configuration Management 

• High cohesion/low coupling

  • Remove internal dependencies

  • communicate through event driven architecture

• Service Autonomy

  • Totally standalone component without depending on another micro-service, which decrease the coupling, and increase cohesion

  • Totally standalone component without depending on another data model

• DB Per Service: So micro-service architect can do the following:

  • Select database type (relational/non-relational)

  • Database provider: SQL/Oracle

• Observability

  • Side-Car pattern

  • Logs classification model, which defines what to be logged from business and technical perspective.

  • Logging tool: like using EFK and ELK

So, database is totally independent, and no one can access it without accessing the micro-service.

In migrating monolithic application to micro-services architecture, teams are familiar with the database structure, and try to reduce the effort by direct access to the database objects, and conduct CRUD operations using triggers, or procedures.

This is violation to the micro-services architecture, as it will block the sunset process for the monolithic solution, in addition, killing the traceability for the micro-services architecture.

• Deplorability

• Event-Driven

In order to architect for modular solution, and for sure, micro-services architecture, the core issue is how can you slice your micro-services?

Here what We answer:

It's DDD: Domain drive design.

So what is domain?

Domain is a discrete part of the system that will help to solve specific problems, So you should have the following:

• Contexts: The high level parts of the solutions, which may be: 

  • Domain generic Model: which Serve the generic infrastructure for the model, from both business and technical perspective

  • Domain specific model

  • Business components: which is the target deliverables of the solution, like User management, Sales, and Purchasing modules

  • Technical components as enabler for the solution: which support the overall solution functionality, from technical perspective, like logging, reporting, and locking.

• Entities and value : The definition of the expected entity objects, and the related values objects

• Aggregator: Which aggregate entities, and values to treat specific unit, it can be used by the aggregator design patterns

• Services: The related business and operations, which will be encapsulated in, Services, modules, or detailed controllers and implementation classes

• Repositories: the storage, which you should apply database per service approach, and it can be:

  • Database level: Which moving forward to containerization approach of the database, to have separate, deployable component from the ecosystem, totally independent to enable standalone deployment 

  • Schema level: Which schema is complex, that require different tables, and views to handle the business 

  • Table level: Which represents the simplest data-model form

• Events: What to publish, and what to subscribe, which should be applied using publisher subscriber design pattern

• Anti-Corruption layer: to ensure that contexts are collaborated and interact without negative impacts or inconsistencies

Due to the software development journey, a lot of source code issues and problems have arise, with huge effort from developers over the world to take action to solve it.

Due to the best practices of solutions, it moved to be a well known solution for the problems, within specific context, which take the name of : Design pattern.

 With the evolution of Cloud architecture, a parallel evolution take place for the cloud, and named with Cloud design patterns.

These design patterns are useful for building reliable, scalable, secure applications in the cloud.

Each pattern describes the problem that the pattern addresses, considerations for applying the pattern, and an example based on Microsoft Azure. Most patterns include code samples or snippets that show how to implement the pattern on Azure. However, most patterns are relevant to any distributed system, whether hosted on Azure or other cloud platforms.