Where We Left Off Previously In the previous architecture spotlight entry, we discussed Event Sourcing and illustrated the concept with a simple banking account example. We laid out many of its pros and cons to help readers decide if the pattern would be useful to them. In this post, we will be expanding the example
Your team realizes that testing is valuable. Your team creates tests for already completed features. The result was encouraging and your team even found a few bugs hiding in the application. Your team returns to feature development and attempts to add new tests. Features took more time to complete because of the need to create
Your software development team released an MVP application into production. The application only had a few features and the codebase is far from perfect, but there are big plans for the future! Your team presses on, adding features and your user base continues to grow. After a few months, cracks begin to surface. Users started
What is Software Architecture? Software architecture is the analysis, thought and design considerations that form the foundational scaffolding for a successful software system. If you write software for work or as a hobby, whether you know it or not, you’re already dealing with software architecture and the processes of making architectural decisions within your applications.
There’s an old adage in the software industry – premature optimization is the root of all evil. A corollary to this should be – no optimization is just as bad as premature optimization. It is often true that effort spent optimizing a system before features are properly implemented, correct and stable is effort wasted, but
SitePen is a huge advocate for TypeScript and the benefits of having well typed code. TypeScript is especially powerful when used by medium and large teams that want to find ways to increase their overall confidence in their code. One of the questions we get asked often is how can we migrate a codebase that
Event sourcing is a powerful architectural pattern that records all changes made to an application’s state, in the sequence in which the changes were originally applied. This sequence serves as both the system of record where current state can be sourced from, as well as an audit log of everything that happened within the application