#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 where you run into massive problems on more complex systems.
Taking this a little bit further, having a clean model of the problem domain also makes other downstream aspects easier. Business analysts can start expecting certain types to have certain properties and you can leverage things like SQL to dramatically speed up projection of business facts without involving developers.
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.
I consistently have to argue with my brother about this, who started developing in the 90s and has a perfect memory for mapping terms to abstract objects.
He argues that at some level, every construct is just assembly that shuffles bits around, so nomenclature doesn't matter (he also grew up with Perl as a first language...). My argument is that it makes his code unreadable without a graph unraveler.
I once spent a long time trying to work through all of the complexities just for what "Customer" meant in one fairly large organisation. Pretty much all followed from one chap asking "if a customer consolidates it finance team from being at each of their 40 sites in one country to 1 shared service centre, do we lose 39 customers"?
Identifying bounded contexts is a critical part of organizing extremely complex systems. You might have a Customer model that supports all contexts of usage, but in a certain bounded context you could know that only certain things from that type are applicable. There are a lot of ways to model this explicitly, but sometimes just having a clear document that expresses what these contexts are and what is involved in each is sufficient.
This also alludes to the benefits around separating your functions from your data. If your domain model is just data and the functions live elsewhere (i.e. within a separate abstraction representing each bounded context), then you have tremendous amounts of flexibility with how the system is composed on top of the model.
Taking this a little bit further, having a clean model of the problem domain also makes other downstream aspects easier. Business analysts can start expecting certain types to have certain properties and you can leverage things like SQL to dramatically speed up projection of business facts without involving developers.