Planning

Despite the large number of application design approaches, two main ones stand out: Transaction Script Domain Model The first is simple and allows for conveniently organizing code into separate procedures that process external requests. However, as application logic becomes more complex, spreading it across many procedures leads to code duplication and other issues. Furthermore, mixing database interaction with logic processing complicates unit testing and reduces code reliability. On the other hand, using a Domain Model at the start often seems like over-engineering, adding significant code without guaranteeing freedom from errors. However, in the long term, this approach enables the creation of programs with complex domain logic without an exponential increase in complexity. ...

I’ve always been skeptical about version numbering starting from zero. Versions like 0.5.2, and especially 0.1.0, still bother me. They imply a sense of incompleteness. Who came up with such strange numbering? If starting from zero, why not 0.0.0? I assume it seemed convenient to number preparatory work—whose utility isn’t self-evident—and then switch to 1.0.0 upon release. What about Version 2? A logical question arises: what about version 2.0.0? We cannot use 1.X.X versions for its preparation. It might seem logical to use even versions for development and odd ones for release. However, this practice is rare as it confuses those unfamiliar with it. For example, it’s confusing when version 3.0.0 follows 2.7.5 with no significant differences. ...