Practice vocabulary for raising architecture concerns in code review: data model changes, abstraction boundaries, service extraction, and PR architecture language.
0 / 5 completed
1 / 5
A reviewer writes: 'This changes the data model in a breaking way.' What concern is being raised?
A 'breaking data model change' means the change (e.g. renaming a column, changing a field type, removing a field) will break existing clients or data. The reviewer is flagging the need for a migration strategy, versioning, or backward compatibility.
2 / 5
A reviewer comments: 'The abstraction boundary isn't clear here.' What does this mean?
An unclear abstraction boundary means the code mixes concerns that should be separated — e.g. business logic bleeding into the data access layer, or presentation logic in a domain model. This leads to coupling and maintenance problems.
3 / 5
During code review, a senior engineer writes: 'I'd suggest moving this to a separate service.' What architecture concern does this reflect?
Suggesting service extraction in a review means the reviewer sees that the new functionality has different characteristics (scaling needs, team ownership, deployment frequency, or domain) that make it a candidate for microservice extraction.
4 / 5
What does a reviewer mean by 'this PR introduces a cross-cutting concern'?
Cross-cutting concerns (logging, security, error handling, caching) cut across multiple modules. A reviewer flagging this is suggesting the implementation should use a centralised pattern (middleware, aspect, decorator) rather than scattered ad-hoc implementations.
5 / 5
A reviewer says: 'This change has significant coupling implications.' What are they pointing out?
Coupling implications mean the change creates a dependency between components that now know too much about each other. High coupling makes refactoring risky and testing harder — the reviewer is asking for a more loosely coupled design.