3. Each service does 1 thing nothing more. That one thing might be 4 different pieces.
4. Tests are unit tests per service, and you should have 100% coverage. We are primarily node.js and use mocha for our tests.
5. Services never talk directly to each other. A message queue or bus architecture should keep services from talking to each other. Yes this adds complexity but it prevents laziness from causing fragility in the system.
6. Have integration test that test functional requirements that span multiple services. This lets you confirm that version updates of one or two services hasn't broken anything.
If you have specific questions let me know. We screwed up a bunch but I think found a good path now.
1 comment
[ 4.0 ms ] story [ 30.6 ms ] thread1. Each service is an island, treat it as such.
2. Each service gets its own source repository.
3. Each service does 1 thing nothing more. That one thing might be 4 different pieces.
4. Tests are unit tests per service, and you should have 100% coverage. We are primarily node.js and use mocha for our tests.
5. Services never talk directly to each other. A message queue or bus architecture should keep services from talking to each other. Yes this adds complexity but it prevents laziness from causing fragility in the system.
6. Have integration test that test functional requirements that span multiple services. This lets you confirm that version updates of one or two services hasn't broken anything.
If you have specific questions let me know. We screwed up a bunch but I think found a good path now.