DDD and analytics - is everything a value object?

Question

(This relates to the problem domain I have previously elaborated on here - though the exact details are not that important for this question)

I'm writing an analysis application for Blockchain (DeFi) smart contracts to help me learn DDD.

The source of truth for data and state is in fact the blockchain. I can always go to a blockchain node and query it for the latest up-to-date state. I parse this state into domain objects to perform my analysis.

I now have two related questions

1) Given I have no need to mutate or track the state of my objects then should they just be value-objects?

All I need is to query the blockchain and build objects that reference each other from memory. I can at any point go back to the source of truth to construct the current state of them.

What confuses me is that in the domain of Blockchain and smart contract the business domain is the technology domain, and every "thing (deliberately not saying entity" yet) has an intrinsic unique ID namely it's address. And while the blockchain needs to most definitely track state/life-cycle of these "things" my app really doesn't care and can just record this contract address as yet another attribute/property.

2) What happens if I want to cache/store calculation results persistently?

Now although I can just go back to source the computation and parsing is "expensive". If I wanted to persist the model and calculation results in my own data store does the answer change?

In this case I'm thinking I'd almost create another model which I use to capture/freeze and store computed state at a point in time. It wouldn't make much sense to persist the entire complex data structure as all that is needed is some base properties and meta-information computed about them.

• Filip Milovanović: I'm not sure if I'll be able to post a proper answer, but I wanted to address certain points of confusion here in comments. The primary characteristic of value objects is not that they are immutable (although most of the time it makes sense to make them so), it's that two different instances that contain the same data are equal for all intents and purposes. If the immutable objects have an extrinsic identity associated with them (e.g. a GUID), important to the users, and that makes them different even though their conceptual value is the same, then they are entities. 1/3
• Filip Milovanović: Also, OOP-style objects (which are not just data structures) can be immutable. These objects may potentially expose no state, instead, think of them as pre-made bundles of related functions/behaviors, parameterized at construction time, that you can then pass around. These are also not value objects; these can instead act as aggregate roots, repositories, or services (yes, services can be objects). Finally, note that all these categories - value objects, entities, aggregates, services, repositories, all of it - are not meant to be architectural. 2/3
• Filip Milovanović: The original DDD blue book introduces them as "tactical patterns"; i.e. they are examples of things you can use to organize your model in some way; DDD doesn't require you to use any of them. DDD is not a particular prescription on how to build systems. It's about how to approach modeling and designing them. There are other approaches to constructing a system within DDD, e.g. event sourcing. My point is, it's not against DDD to mess with the design to suit your particular problem; just make your domain model explicit in the code. 3/3
• Filip Milovanović: P.S. The "blue book" I was referring to: Domain-Driven Design: Tackling Complexity in the Heart of Software
• Laiv: In this case I'm thinking I'd almost create another model which I use to capture/freeze and store computed state at a point in time this a change log and yes, all are value objects because all the entries points to the past. Like events in a event log.

Answer 1

Sure why not? But if that’s the case you are going to be missing a significant part of the DDD experience: the aggregate root.

But if you don’t need one you don’t need one. DDD is not the one size that fits all. Maybe solve some other problems with DDD while you’re trying to learn.

As always, your real problem knows what you need far better than any book does. Let it teach you.

• Sev: So the reason I thought DDD is a good fit here is that the calculations I need to do are quite complicated and depend on relations of "value objects" to each other. Therefore it helped me to model the business elements in this way. Example why I think DDD fits "a token value object needs to derive its value based on the ratio of it to another asset in a liquidity pool". That requires traversing multiple objects and inferring intermediate values on them. I believe VOs still give me that benefit even without needing aggregate assured consistency