Embrace no-code to explore more models and throw most of those models away. You will quickly discover what works, and what matters, in the business process that you are automating. If it matters enough, you can extract it into a high-fidelity design in code.
Many software projects still consume considerable resources, and take a long time before anything material is put in the hands of the end-user. At a smaller scale this happens with teams that have the ambition to adopt Domain-Driven Design principles but that lack the expertise and experience in how to approach the design process. There is a spectrum of mistakes. On one hand there is the lack of producing a meaningful and shared model that is able to unify the conflicts and handle the complexity that the messy world will serve the system. On the other end of that spectrum there is analysis paralysis: a model that never sees the light of day, because there is always a new case it cannot handle. If the team doesn't produce a meaningful model, or if it fails to put that model in front of experts early on, then the team robs itself of precious feedback. "Judge models by their usefulness" is a mantra that is difficult to live by, if the model isn't being used…
Despite warnings, teams design big architectures early on, to support even bigger ambitions of the organization they work for, but they forget that it's not the architecture that the end-user cares about. With every bit of structure that is added early on, the team reduces the degrees of freedom to evolve the system at a later point in time. In order to support long-lasting design that is attuned to the environment, teams should set architectural principles that allow for a helpful structure to emerge, regardless of the platform.
