Here are a few examples of things that the answer depends on, to help you out:
- The project; for example:
- Domain-heavy or logic-intensive projects will benefit from a domain layer, helping you centralize parts for an augmented level of reusability and maintainability.
- Data management projects tend to have less or no logic in them. We can often build them without adding a domain layer as the domain is often only a tunnel from the presentation to the data; a pass-through layer. We can often simplify those systems by dividing them into two layers: data and presentation.
- Your team; for example, a highly skilled team may tend to use advanced concepts and patterns more efficiently, and the learning curve for newcomers should be easier due to the number of seasoned engineers that can support them on the team. This does not mean that less skilled teams should aim lower; on the contrary, it may just be harder or take longer to start. Analyze each project individually and find the best patterns to drive them accordingly.
- Your boss; if the company you work for puts pressure on you and your team to deliver complex applications in record time and nobody tells your boss that it is impossible, you may need to cut corners a lot and enjoy many maintenance headaches with crashing systems, painful deployments, and more. That being said, if it is inevitable for these types of projects, I’d go with a very simple design that does not aim at reusability—aim at low-to-average testability and code stuff that just works.
- Your budget; once again, this often depends on the people selling the application and the features. I saw promises that were impossible to keep but delivered anyway with a lot of effort, extra hours, and corner-cutting. The thing to remember when going down that path is that at some point, there is no return from the accumulated technical debt, and it will just get worse (this applies to all budgets).
- The audience; the people who use the software can make a big difference to how you build it: ask them. For example, suppose you are building a tool for your fellow developers. In that case, you can cut corners that you would not for less technically skilled users (like delivering a CLI tool instead of a full-blown user interface). On the other hand, if you’re aiming your application at multiple clients (web, mobile, and so on), isolating your application’s components and focusing on reusability could be a winning design.
- The expected quality; you should not tackle the problem in the same way for building a prototype and a SaaS application. It is acceptable, even encouraged, for a prototype to have no tests and not follow best practices, but I’d recommend the opposite for a production-quality application.
- Any other things that life throws at you; yes, life is unpredictable, and no one can cover every possible scenario in a book, so just keep the following in mind when building your next piece of software:
- Do not over-engineer your applications.
- Only implement features that you need, not more, as per the you aren’t gonna need it (YAGNI) principle.
- Use your judgment and take the less-worst options; there is no perfect solution.
I hope you found this guidance helpful and that it will serve you in your career.
