N-tier architecture, also known as multitier architecture, is an architectural pattern in software engineering that physically separates functions responsible for data storage, business logic, presentation, and more.
Splitting an application horizontally into multiple layers, each serving a specific purpose, helps maintain the separation and decoupling of components. This approach also assists in maintaining a general overview of the application.
However, adhering to good software development practices, such as the single responsibility principle, is still dependent on the developer's responsibility. Without proper attention, things can end up badly.
For instance, if business logic spreads from services into controllers and more logic ends up in JSPs, you may soon find yourself in a challenging situation. These things can slow down investigations and make significant architectural changes difficult or even impossible. Or covering things with unit and integration tests retroactively might not make sense in such cases. They might not bring wider code coverage.
Such things end up covered mainly with expensive, brittle end-to-end tests, slowing down time to deployment. These tests can occasionally randomly fail and might require repeated re-running. Detection of bugs is pushed more into the future, making their fixing more expensive, and failed end-to-end test might not say where a problem is exactly. This makes it harder to figure out what is wrong because you must usually go through multiple layers. It is good to keep things in proper places, where they can be tested cheaply with unit and integration tests. This is also a good reason to start to think in a more Test-Driven Development (TDD) way. It can motivate you to keep logic in places where it is easier to test it.
While N-tier architecture is beneficial, it's essential to maintain good programming practices alongside it.
No comments:
Post a Comment