0

I'm starting with Domain Driven Development and after a lot of reading I'm trying to refactor an application the DDD way. But I'm facing a fundamental problem and not sure how to solve.

As an introduction some simplified tasks my application should do. It is a course booking application:

  • A course consists of Category, DateTime, Description and Location
  • Categories and Locations can be selected from a Dropdownbox
  • A special settings section give the user the possibillity to add and change categories and locations

I'm a little bit confused about the immutable state of an object. First I thought a lcoation for example has to be a entity object because it has a identity. But in scope of course the location itself is immutable and cann't be changed.

I'm really confused. Can anybody help me to clear my view?

Dirk Beckmann
  • 1
  • 2

3 Answers3

1

Category and Location are examples of what Vaughn Vernon calls standard types in his book Implementing Domain-Driven Design. Although the discussion in the book is in Chapter 6 - Value Objects, he suggests that the standard type should be an entity in its native BC, and we should try to treat them as VOs in the consuming BC:

We may think of these as Entities because they have a life of their own in a dedicated, native Bounded Context. Regardless of how they are created and maintained by any kind of standards body, if possible we should strive to treat them as Values in our consuming Context. [...]

For the sake of maintenance it is common for Standard Types to natively reside in a separate Context from the models that consume them. There they are Entities and have a persistent life cycle with attributes such as identity, name, and description.

(BTW, Vernon mentions that this kind of object he calls standard type is aka lookup and type code.)

Community
  • 1
  • 1
Paulo Merson
  • 13,270
  • 8
  • 79
  • 72
0

If locations can be managed independently of courses (add, edit, remove, etc.), then locations are most likely an independent aggregate root. You would change your course to reference the id of its location, instead of containing a location.

I'd do this, because locations are limited, you would probably want to look at modelling them as entities (i.e. they're something you're going to want to store and put ids against, as opposed to something like student's home addresses, which would most likely always be value objects, as they have no mutability or reusability), with location as the aggregate root, with each location having an address property which would be a value object (if you're using SQL, then the address can be denormalised and stored in-row with the location data).

If you don't want developers to be able to modify any properties of a location, then you can design your classes to prevent modification.

Adrian Thompson Phillips
  • 6,893
  • 6
  • 38
  • 69
0

The decicision is based on how you identify them.(not imutability)

Location is usally an entity. But in some cases, value object is also fine if you just care the identifier.

@Entity
Location {
    @Identifier private String code;

    //many other mutable properties
}

@ValueObject
Location {
    private String code;//the only property
}

DDD is not good at domains like product infomation or other Content managment oriented things. I would rather keep the original structure but find a small subdomain to refactor like inventory or pricing.

Yugang Zhou
  • 7,123
  • 6
  • 32
  • 60