CQRS/CQS is a way to share data over two micro services via common data source

 Best practice in micro service design is share nothing. every micro service have it own data store. This makes the micro services resilient against slow data provider and resilient against outages of data delivering micro services. But there is one way to speed up this micro service architecture. If you use the CQRS pattern (Query Responsibility Segregation) or CQS pattern (Query Command Separation), my favorite pattern, and combine it with micro services.

Service A write or modify data only e.g. import billing data as large CSV  from the main frame. And Service B (E-Commerce-Backend) read only the data. Service B doesn't alter the data, it's a read only service. Both services using the same data source. Under this conditions (CQS) a common data source is a save and easy way to handle common data in a micro service environment.

Agile Anti-Pattern: Architectural Decision Records (ADRs)

Architectural Decision Records (Link) are ... a decision log. How can ADRs improve the agile software development? What is the ADR benefit? I can't see it. For me ADRs looking like an 'cover your ass' thingy. After reading most of the linked articles, I'm very confident that ADRs are a new kind of the obsolete old Waterfall  Software Development with a cool name. It breathes the old idea that it is possible to catch all software requirements before we start to developing. This wrong assumption lead us to the first software crisis, it's proven false in the 90s and in 2022 too.

Suggestions:

1. Don't use ADRs
2. Talk with your real customers and write extensive user stories
   

How to build stable and reliable System Test for Micro Services

Work in Progress, I'm currently overwork this article. Please come back later!

 

 

System tests are testing the orchestration of a bunch of micro services. Most of the test covers external features used by other micro services or by the front end.

If the current micro service is optimized for resilience (Yeah, Great) then system tests on feature endpoints can't discover errors related to (incoming) dependend micro services. The root cause of this lower power system test is the decoupling of micro services eg via the Fail Fast Pattern  or other Circuit Breakers (Thanks to Netflix). Or with other words resilience pattern could reduce the value of system tests.

System Tests improved by Diagnostic Endpoints

One way to avoid this negative side of resilience is to introduce what I called Diagnostic Endpoints. A diagnostic endpoint is only used by system test an not by features. The goal of diagnostic endpoints are to verify that functions that are covered eg by resilience pattern work.

In the real world, we save a huge amount of time after establishing of diagnostic endpoints. The software developers and the Project Owner love them.