Your business value proposition may rely on several applications working together. However, when implementing a new feature or refactoring an existing one, we sometimes forget the application’s identity and introduce unnecessary performance issues or added complexity.
I like to explain this with examples.
Imagine you are a developer on a team responsible for building a Hospital Information System (HIS). You need to implement a feature that periodically identifies patients missing required personal data, evaluates them using some business logic (including synchronous actions), and—using the Outbox Pattern—sends emails encouraging them to update their profiles.
Now, suppose you have millions of patients in your database and need to evaluate a significant portion of them. Would you process them in batches of 1,000 and evaluate them in parallel (keeping in mind the synchronous operations)?
Your application’s identity should guide your decision. Its primary mission is to support patient-related workflows: retrieving patient information, maintaining clinical histories, creating procedure requests, or scheduling appointments. The performance and availability of these core functionalities must not be impacted by secondary features like requesting missing data. You should find a way to implement this feature without degrading the system’s core responsibilities.
On the other hand, in a microservices architecture, you may have bounded contexts, and a new feature might span two or more services. Take the time to determine which microservice is the right place for the implementation. Think carefully about the identity of each service and whether the new feature aligns with it or introduces unnecessary coupling.
Finally, keep the application’s identity in mind when deciding the appropriate level of testing and where to draw the line for “good enough” software.
Any questions or experiences to share? I’d love to read them in the comments.