#2 is probably the most important. How you model the domain is the most foundational part of any software system. If everyone on your team looks at your domain model and thinks "yep that makes total sense", then it is very likely the rest of the project can be made to go smoothly. If the meaning of a Customer or User in your system is ambiguous, or has certain nuances privy only to the architecture team... this is wh…
I agree. This is the classic “you don’t understand it if you can’t explain it” problem. If you don’t have the domain nailed down in plain speak, there are risks to productivity - especially if an entire team is involved. Business logic becomes open to interpretation at implementation time. That means a different solution for any developer who happens to implement it, and each one potentially incorrect and unable to interface with correct code in its own way.
I’ve set myself up for failure this way, essentially by assuming things would just fit into place as more of the project became clear. That’s a really bad way to work, haha. But you learn as you go.