1

(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.

5
  • 1
    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 Jun 30, 2021 at 15:12
  • 1
    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 Jun 30, 2021 at 15:13
  • 1
    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 Jun 30, 2021 at 15:13
  • 1
    P.S. The "blue book" I was referring to: Domain-Driven Design: Tackling Complexity in the Heart of Software Jun 30, 2021 at 15:13
  • 1
    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.
    – Laiv
    Jun 30, 2021 at 16:12

1 Answer 1

3

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.

1
  • 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
    – Sev
    Jun 30, 2021 at 6:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.