Now that we covered all of this, it is important to note that on the one hand, there is the theory, and on the other, life is hitting you in the face. Suppose you are working in a big enterprise. In that case, chances are your employer can pour hundreds of thousands or even millions of dollars into a feature to run experiments, spend months designing every little piece, and ensure everything is perfect. Even then, is achieving perfection even possible? Probably not.For companies that don’t have that type of capital, you must build entire products for a few thousand dollars sometimes because they are not trying to resell them but just need that tool built. That is where your architectural skills come in handy. How do you design the least-worst product in a maintainable fashion while meeting stakeholders’ expectations? The most important part of the answer is to set expectations upfront. Moreover, never forget that someone needs to maintain and change the software over time; no software does not evolve; there’s always something.
If you are in a position where you must evaluate the feasibility of products and features in this context, setting expectations lower can be a good way to plan for the unplannable. It is easier to overdeliver than justify why you underdelivered.
Let’s dig deeper into this and look at a few tricks to help you out. Even if you are working for a larger enterprise, you should get something out of it.
To be or not to be a purist?
In your day-to-day work, you may not always need the rigidity of a domain layer to create a wall in front of your data. Maybe you just don’t have the time or the money, or it’s just not worth doing.Taking and presenting the data can often work well enough, especially for simple data-driven applications that are only a user interface over a database, as is the case for many internal tools.The answer to the “To be or not to be a purist?” question is: it depends!
This section covers layering, but we explore other patterns that are feature-oriented, so I suggest you continue reading and explore using the techniques from Chapter 17, Vertical Slice Architecture, Chapter 18, Request-EndPoint-Response (REPR), and Chapter 20, Modular Monolith, to improve your design while keeping the design overhead low.
