0

Using domain driven design, where are simple value objects/entities instantiated?

For example, if i needed to create a simple value object in a service class, would I just call the new operator on the value object's class, coupling this to the service class?

Can the new operator be called in a service class according to domain driven design?

These value objects can't be injected through a DI container and they don't warrant the use of a factory because of their simplicity.

Bojs
  • 103
  • 2
  • 9
  • 1
    What has that to do with domain driven design? Your question is unclear. Why don't you instanciate the values in the classes where they are relevant? Show us some code and/or examples please. – Angel O'Sphere Oct 21 '15 at 12:00
  • It is unclear. I'll edit it. But, i want a loosely coupled design, so I can't instantiate them directly in the method that uses them, i'd need to pass them in. Therefore, I need to know where to instantiate them if they are basic objects and not complicated aggregates that warrant the use of a factory. – Bojs Oct 21 '15 at 20:18

1 Answers1

3

What's wrong with instantiating them directly from their constructor?

Usually you only want factories when the instantiation process is complex or when you want to relieve the client from choosing a concrete class.

However, since the ubiquitous language is crucial in DDD it's quite common that an aggregate will have factory methods to create other aggregates to which they relates.

For example, rather than spawning project tasks out of thin air like below:

var task = new Task(projectId, ...);

You could do:

var task = project.addTask(...);

That would express the "tasks can be added to projects" use case better at the cost of having to load a Project aggregate.

plalx
  • 42,889
  • 6
  • 74
  • 90
  • I want to know where to create simple value objects. I know they can be created from the repository and passed in by the client of the app, but what about when my services need to create their own? How do I go about doing this without tightly coupling the classes? If they are so simple that a factory would be overkill, then where do I create them? They can't be injected through a DI container because they are value objects. – Bojs Oct 21 '15 at 20:25
  • @Bojs I really don't get what you mean by where? You just instantiate them where you need them. What you are asking is the same thing as where do I create strings, integers, dates, etc. in an application... it makes no sense. You will obviously be tightly coupled to VOs. – plalx Oct 21 '15 at 21:31
  • is that the standard practice according domain driven design? have any links you can share to online material? – Bojs Oct 22 '15 at 00:39
  • @Bojs Your question is too unclear. What bothers you? – plalx Oct 22 '15 at 03:04
  • 2
    Bojs, you're trying to go too far with loose coupling. Domain objects shouldn't be loosely coupled to because they are intrinsically concrete, univocal things. See http://stackoverflow.com/questions/16972974/ddd-and-domain-interfaces-classes http://stackoverflow.com/questions/16041804/should-an-aggregate-root-implement-an-interface-in-domain-driven-design (about entities, but same is true for VO's) – guillaume31 Oct 22 '15 at 09:55