Different Aggregate Root States in Domain Driven Design

Question

I have read the Domain Modeling Made Functional book.

In the book, the author model the Order in 3 different states:

1. Unvalidated
2. Validated
3. Priced

The 3 states have different properties.

But it's functional programming.

I find it's hard to implement in Object-oriented programming. Since the 3 states only have different properties, not different methods, the state machine pattern is not quite correct to be implemented here.

I have come up with a solution like this:

abstract class Order extends AggregateRoot {}

class UnvalidatedOrder extends Order { // Unvalidated properties }

class ValidatedOrder extends Order { // Validated properties }

class PricedOrder extends Order { // Priced properties }

This solution, however, makes the aggregate root hard to persist, because I have to check the type of the object using if/else every time.

I could make it easier if I use specific method to persist specific type of Order, but does that makes them 3 aggregate roots?

Could you please show me how to model states of aggregate roots in Object-Oriented Programming?

Answer 1

In object-orientation you generally tell an object to do things instead of asking it for data and trying to do it yourself. In other words, a very simple solution is to ask the object to persist itself.

You could also call this polymorphism, if you have different types for different states and still want to tell the same thing to each of those (i.e. persist yourself).

Ideally though, you wouldn't even necessary need to ask. An object should persist itself as part of the business-case at hand, as needed. I mean why would you assume that an object needs persisting from the outside? The object already knows everything it needs to know about itself.

This clashes with some interpretations of DDD, where the "model" is just data structures and "repositories" routinely get data out of objects and persist them without the objects involvement.

About the "functional DDD" book.

I've written enough Haskell (and some functional Scala and Kotlin+Arrow code) to be somewhat familiar with FP. I'm not familiar with the book, but I did look at the code. I do not like that code.

The big idea (in my opinion) of DDD is to concentrate on the domain. Let the design be about the domain, the common language, instead of technical stuff.

Now just look at the names on top level. There are appr. 20 words in there, not counting repeats. About 2 of those connected to the use-case: "PlaceOrder" and "Pricing". All others are technical, like: Api, Dto, Implementation, InternalTypes. Now sure, some scaffolding is always needed, but 90%?

Now try to find out what this code actually does. What is the business case? It is really hard. There is a "PublicTypes" file. That only contains data structures. Which is implementation detail, noone cares.

Third, what is "UnvalidatedOrder" anyway? Is that really a thing? I suspect it is just a technical thing and has nothing to do with the common language. I mean it is really fancy (it would be even more fancy if Unvalidated[T] would be a Monad btw.), but it is a technical thing. Technical things are not cool in DDD. Neither in good OOD.

That is just from 15 minutes looking at the code, so take this part about the book with a grain of salt!