How should we design communication between microservices? Should it be synchronous or asynchronous? Should it be direct or through message brokers, event bussed, and gateways?Continue reading
Tag Archives: software architecture
This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.
- Part 1: Introduction
- Part 2: Narrative
- Part 3: Scenarios
- Part 4: Automation
The goal of software projects is to deliver value to stakeholders. Even though that might sound an obvious statement, it can be easily forgotten in traditional Waterfall projects. The very nature of the Waterfall process fosters the creation of different departments whose job is to receive work from the previous stage, produce something, and pass it on.
A simplified Waterfall model would be:
- Requirements specification resulting in requirements document
- Design resulting in software architecture document
- Development resulting in actual software
Each of these phases tends to have separate teams and departments. BAs work with requirements, architects write design documents, developers code, integration engineers integrate, testers test, and someone installs the software. Each of these departments is waiting for others to produce something, to start working on their artifacts and, once finished, to pass it on to someone else. The value for the stakeholders is, in many cases, unknown or forgotten. Most people involved in such projects are concerned about “doing their part” and throw it “over the wall” to those coming next. Moreover, artifacts produced by one team are often not used or understood by another.