It's perfectly fine - indeed, it's a good idea - to use dependency injection in your domain model.

You should to develop your domain model independently of any particular technology or library. The particulars of such-and-such database or so-and-so library are not the concern of your domain model: if you need to swap databases your business rules will remain the same. So we apply the dependency inversion principle and depend on interfaces which address the concerns of the domain model and adapters which adapt a given technological concern to the domain. (Importantly, the interface is phrased in terms of domain-level operations and lives in the same package as your domain classes.)

A great example of this is the Repository pattern. The Repository adapts the database to an interface which suits the domain model. So you can write customerRepository.FindByEmailAddress(email) and not worry about the exact SQL statements that retrieve the customer for you. And by depending on an interface, your domain model has no idea whether it's a SQL database, a file, or MongoDB or Neo4j, or whatever.

So the Dependency Inversion Principle, and Dependency Injection, is of tremendous use in DDD. What I think is a less good idea is keeping your domain in an IOC container. The problem is that you end up storing domain-level information (like how to attach an order to a customer) away from your domain classes in a configuration file somewhere. IOC hides details that shouldn't really be hidden from your domain model. Also, the details of your particular container tend to leak into your domain classes.

Use IOC at the boundaries of your system, if you must, to wire up command handlers and other API services. Use dependency inversion and dependency injection in your domain model whenever it makes sense to do so, but keep IOC out of the picture.

It's perfectly fine - indeed, it's a good idea - to use dependency injection in your domain model.

You should to develop your domain model independently of any particular technology or library. The particulars of such-and-such database or so-and-so library are not the concern of your domain model: if you need to swap databases your business rules will remain the same. So we apply the dependency inversion principle and depend on interfaces which address the concerns of the domain model and adapters which adapt a given technological concern to the domain. (Importantly, the interface is phrased in terms of domain-level operations and lives in the same package as your domain classes.)

A great example of this is the Repository pattern. The Repository adapts the database to an interface which suits the domain model. So you can write customerRepository.FindByEmailAddress(email) and not worry about the exact SQL statements that retrieve the customer for you. And by depending on an interface, your domain model has no idea whether it's a SQL database, a file, or MongoDB or Neo4j, or whatever.

So the Dependency Inversion Principle, and Dependency Injection, is of tremendous use in DDD. What I think is a less good idea is keeping your domain in an IOC container. The problem is that you end up storing domain-level information (like how to attach an order to a customer) away from your domain classes in a configuration file somewhere. IOC hides details that shouldn't really be hidden from your domain model. Also, the details of your particular container tend to leak into your domain classes.

Use IOC at the boundaries of your system, if you must, to wire up command handlers and other API services. Use Dependency Inversion and Dependency Injection in your domain model whenever it makes sense to do so, but keep IOC out of the picture.

It's perfectly fine - indeed, it's a good idea - to use dependency injection in your domain model.

You should to develop your domain model independently of any particular technology or library. The particulars of such-and-such database or so-and-so library are not the concern of your domain model: if you need to swap databases your business rules will remain the same. So we apply the dependency inversion principle and depend on interfaces which address the concerns of the domain model and adapters which adapt a given technological concern to the domain.

It's perfectly fine - indeed, it's a good idea - to use dependency injection in your domain model.

You should to develop your domain model independently of any particular technology or library. The particulars of such-and-such database or so-and-so library are not the concern of your domain model: if you need to swap databases your business rules will remain the same. So we apply the dependency inversion principle and depend on interfaces which address the concerns of the domain model and adapters which adapt a given technological concern to the domain. (Importantly, the interface is phrased in terms of domain-level operations and lives in the same package as your domain classes.)

A great example of this is the Repository pattern. The Repository adapts the database to an interface which suits the domain model. So you can write customerRepository.FindByEmailAddress(email) and not worry about the exact SQL statements that retrieve the customer for you. And by depending on an interface, your domain model has no idea whether it's a SQL database, a file, or MongoDB or Neo4j, or whatever.

So the Dependency Inversion Principle, and Dependency Injection, is of tremendous use in DDD. What I think is a less good idea is keeping your domain in an IOC container. The problem is that you end up storing domain-level information (like how to attach an order to a customer) away from your domain classes in a configuration file somewhere. IOC hides details that shouldn't really be hidden from your domain model. Also, the details of your particular container tend to leak into your domain classes.

Use IOC at the boundaries of your system, if you must, to wire up command handlers and other API services. Use dependency inversion and dependency injection in your domain model whenever it makes sense to do so, but keep IOC out of the picture.