“Good judgment comes from experience, and experience comes from bad judgment.
— Fred Brooks”
Every time we are engaged on a software project, we create a solution. We call the process architecting, and the resulting concrete artifact is the architecture.
This essential pattern for loose coupling focuses on asynchronous delivery of command requests sent from the user interface to a back-end service for processing. This pattern is a subset of the CQRS pattern. The pattern is used to allow interactive users to make updates through the web tier without slowing down the web server. It […]
Continue Reading
This advanced pattern focuses on horizontally scaling data through sharding. To shard a database is to start with a single database and then divvy up its data across two or more databases (shards). Each shard has the same database schema as the original database. Most data is distributed such that each row appears in exactly […]
Continue Reading
The Eventual Consistency primer introduces eventual consistency and explains some ways to use it. This primer uses the CAP Theorem to highlight the challenges of maintaining data consistency across a distributed system and explains how eventual consistency can be a viable alternative. In an eventually consistent database, simultaneous requests for the same data value can […]
Continue Reading
WE OFTEN HEAR SOFTWARE ENGINEERING COMPARED to building skyscrapers, dams, or roads. It’s true in some important aspects. The hardest part of civil engineering isn’t designing a building that will stand up once it is finished, but figuring out the construction process. The construction process has to go from a bare site to a finished […]
Continue Reading
MANY ASPECTS OF INVISIBILITY are rightly lauded as software principles to uphold. Our terminology is rich in invisibility metaphors—mechanism transparency and information hiding, to name but two. Software and the process of developing it can be, to paraphrase Douglas Adams, mostly invisible: Source code has no innate presence, no innate behavior, and doesn’t obey the […]
Continue Reading
AS AN ARCHITECT, you are tasked with providing the initial structure and arrangement of software systems that will grow and change over time, will have to be reworked, and will have to talk to other systems—and almost always in ways you and your stakeholders did not foresee. Even though we are called architects, and we borrow […]
Continue Reading
OF ALL THE PRINCIPLES OF PROGRAMMING, Don’t Repeat Yourself (DRY) is perhaps one of the most fundamental. The principle was formulated by Andy Hunt and Dave Thomas in The Pragmatic Programmer, and underlies many other well-known software development best practices and design patterns. The developer who learns to recognize duplication, and understands how to eliminate […]
Continue Reading
AT SOME POINT, every programmer will need to refactor existing code. But before you do so, please think about the following, as this could save you and others a great deal of time (and pain): The best approach for restructuring starts by taking stock of the existing codebase and the tests written against that code. This will […]
Continue Reading
I KNOW, THERE REALLY IS AN ‘I’ IN ARCHITECTURE. But it’s not a capital ‘I’, calling attention to itself, dominating discussion. The lowercase character fits neatly within the word. It’s there only because it fulfills requirements for proper spelling and pronunciation. How does that relate to us as software architects? Our egos can be our […]
Continue Reading
Software is one big building with many floors and rooms. Architecture is all around you, regardless of the reason why you’re in the building. Like posters on the walls of this building, i want to share this article with some mantras that everybody should take in mind. Mantra #1—It Depends It always depends. As an […]
Continue Reading
While most of us aren’t building websites for banks, medical centers, or the NCSA, it’s still important to focus on and be aware of the possible failure points of our applications. Doing so gives our products an attention to detail that will be appreciated by our user base and will evolve into real, tangible profits. […]
Continue Reading
What is SOLID? SOLID are five basic principles whichhelp to create good software architecture. SOLID is an acronym where:- S stands for SRP (Single responsibility principle O stands for OCP (Open closed principle) L stands for LSP (Liskov substitution principle) I stands for ISP ( Interface segregation principle) D stands for DIP ( Dependency inversion […]
Continue Reading