In DDD, how much the code model have to resemble the analysis model?

Question

In books about DDD, there are so many emphasis on making the code model and analysis model the same (or related). I'm currently reading Patterns, Principles, and Practices of Domain-Driven Design, here's some quotes:

...the code model and analysis model are one, and a change in one will result in a change to the other.

Domain experts and business analysts understand the code model and help to shape it.

Use the [ubiquitous] language to drive the design of your code.

I find this a little bit confusing because sometimes the model in code can be quite different with the analysis model. There are things like design patterns and software architecture. If those can be used, does that mean that business analysts have to understand about it as well and use it in their analysis model?

In the code, the developer is focused on technical abstractions, design patterns, and design principles, whereas the domain expert is focused on business process and work flow. This is problematic. Developers should think in domain terms and concepts, not technical terms, to avoid the need to translate from business jargon into technical jargon.

This seems to suggest to avoid design patterns altogether and to code based on the model that's agreed within the team. What if the analysis model is not performant when implemented in the code?

How much the code model have to resemble the analysis model?

Answer 1

does that mean that business analysts have to understand about it as well and use it in their analysis model?

I don't think so. It seems business analysts in the book that you are reading are domain experts from this great answer:

In using DDD, you are meant to work closely with a domain expert who can explain how the real-world system works. For example, if you're developing a system that handles the placing of bets on horse races, your domain expert might be an experienced bookmaker.

I mean business analysts help to dive into the domain of your application that you build.

Also as msdn says:

Before writing any code, you need a bird's eye view of the system that you are creating. DDD starts by modeling the business domain and creating a domain model. The domain model is an abstract model of the business domain. It distills and organizes domain knowledge, and provides a common language for developers and domain experts.

So I believe domain experts in msdn are equal to business analysts in your book.

Answer 2

This seems to suggest to avoid design patterns altogether and to code based on the model that's agreed within the team

No, it's not the intention. They emphasize using domain terms. For example, ProductFactory is wrong, and ProductCreator is correct. Using pattern names in domain models leaks technical aspects. Just use a name for objects that is natural for them so that domain experts can understand them. It's hard to choose the right name because naming things is one of the hardest things in software development and when you make it more restricted, it gets even harder.