Should I inject things into my entities?

Question

When using an IoC container, is it considered a good design to introduce other classes into it? those. stability class

Answer 1

In general, I advise against this. Objects are exactly what should be a specific and important part of your main domain. They should have one responsibility and be very, very good at it. If the facility requires additional services to complete the task (for example, perseverance), you begin to allow things like infrastructure to penetrate your domain. Even the concept of an invoice that can calculate its billing value is not necessarily the responsibility of the Invoice class. This may require such things as sales tax, shipping costs, customer discounts. Once you open these doors and try to start bringing these items into your account object, it becomes the class of everything. Domain services are better suited to coordinate organizations and provide services to them. Infrastructure services are better suited to such things as resilience and external communications. Both of them perfectly insert other services through IoC (and are encouraged so that they themselves do not become intruders).

Answer 2

This is a spreadsheet context : are you writing a repository .store (entity) or entity.storeIn (repository)?

Each has its own merits. I usually prefer the .store repository (entity) for the main reason that I support the methods of my domain-oriented objects. It makes sense to write pen.dispenseInkOnto (Surface), because that's what pens do. It is a little less sense to write pen.storeIn (penRepository).

The downside is that you need to grant access to the internal elements of the object class to the persistence class. Besides getters that introduce the same problem as entity.storeIn (), I would go with a friend class protected by package access, internal access, or a friend class to restrict access to internal only to those who need it.

As a rule, a general injection of classes, in the example pen.dispenseInkOnto (Surface), you can make the Surface interface and use injection. I see no problem with this if you add other objects, value objects, or services.

Answer 3

I also advise, but would recommend reading the DDD forum , as there are many posts about this. It is doubtful whether it should even be introduced into domain services, in more complex areas, I think not.

As Beale said, services are great for cross-aggregate coordination and, in particular, for any coordination with anything outside the domain.

Answer 4

I would recommend against this.

Typically, your domain is cleaned up when your entities get what they need to do to fulfill their responsibilities. When they have to look for things, they often use shortcuts, shortcuts that can be avoided by doing more analysis in the domain and relationships between members of the domain.

Applications and domain services are generally the best place to inject, in my opinion. They may also be responsible for creating / maintaining facilities.

Answer 5

That's right. This is how you do not bind a class to some specific persistence implementation. Sometimes I write false DAO classes that are "saved" only for memory structures, and I insert them in unit testing.