When it comes to application design, I’ve formed a few opinions backed by experience. The most important one is: structure matters. In my first years of development, I’ve built a CMS system that was copied over more than 100 times for different web pages. You don’t get there unless you repeat the same process over and over.
Application development is like that. If you’re writing one middleware, you want the process to be repeatable for each following middleware.
The more people that work on the project, the more consistent you want the code base to be. Principles like SOLID or DDD give you a repeatable structuring model. Extending your application with a new service or component encourages composition, locality of behaviour, while adding new bounded scopes for testing.
Smaller package scopes lead to better tests, lead to less bugs overall.
There’s two ways to think about this, or rather two principles that apply to application development leaning into composability:
- Use cases for the application
- Data model first principles
As we know, applications can range from cli tooling, services of various sizes providing APIs, REST, gRPC, a package API. A web application may use templating to render a data model into other representations aimed at browsers. There’s variety and the use cases sort of dictate the top level components.
continue reading on titpetric.com
⚠️ This post links to an external website. ⚠️
If this post was enjoyable or useful for you, please share it! If you have comments, questions, or feedback, you can email my personal email. To get new posts, subscribe use the RSS feed.