3

I've tried Googling this using several phrases and I simply can't find this asked anywhere so I hope this isn't too silly a question.

I'm just dipping my toes into DDD and I have a toy project I'm building around Defi in the crypto space. In short the point of the project is to read a bunch of information from smart contracts and then performs some calculation and analysis to determine degrees of token inflation etc.

I've modelled my domain into entities and Value Objects as described below, but I end up with multiple "orphaned" entities that don't seem to fit into an aggregate.

I've not seen this situation mentioned anywhere so I wonder if a single entity is aggregateless or if it simply becomes the root of an aggregate without sub-entities?

This is how I modelled my domain

  • Entity: DeFi Farm (aggregate root) - Represents a DeFi farm containing multiple staking pools. Pools make no sense outside of a farm it
  • Entity: DeFI Staking Pool (part of DeFi Farm aggregate root) - Represents a given pool its reward payout rate etc. Doesn't make any sense outside of an exchange so part of that aggregate
  • Entity: Stakeable asset - Used in Staking pools. Can exist outside of a staking pool though and is sort of independent of the DeFi farm too (reason being a given stakeable asset could be used in multiple farms)
  • Value Object: Token - ERC20 token. Stands on its own. Used by stakeable assets, farms and pools but doesn't need them to exist
  • Entity: Smart Contract - Used by all of the above but makes sense outside of them (i.e. there exist things that use smart contracts that are neither of the things I have in my domain so far)
  • Entity: Blockchain Network - An exchange lives on a given network, but the network happily exists without any of the other things.

So now I'm in a position where Pool, Token, Staked Asset, Token, Contract and Network have a life of their own. Should these be aggregate-less entities or simply entities in aggregates of size 1?

I'm also a bit unsure on Entity vs Value Object here because in Blockchain everything has a unique ID by design (its contract address).

Thanks in advance.

Improve this question
1
  • Entities in aggregates of size 1 would be the usual approach (the entity would be the root of its own aggregate).
    – VoiceOfUnreason
    Jun 12, 2021 at 12:14

1 Answer 1

Reset to default
1

By definition Entities should be part of an Aggregate in DDD. Maybe the Aggregate is very simple: just one entity.

However, to see Aggregate boundaries clearly it is better to focus on the behavior and object lifecycle: commands and state transitions will point you to the objects that will have to change together. If all you have is data with little behavior, maybe you're not in the right place to start.

I'd suggest starting by looking at the actions and focusing on the invariants that have to be guaranteed when mutating state.

Improve this answer
4
  • I wouldn't say "by definition". I agree that it is commonly the case, but not exclusively so. Some data entities might be hidden from the domain by intention, e.g. audit logs. As a simple example, maybe the DAL secretly records any changes made to the database, but the domain never reads those records and therefore has no need for an aggregate to represent them - even though the DAL does need the entity itself in order to create the records.
    – Flater
    Jun 14, 2021 at 12:45
  • 1
    Well, I said 'by definition' intentionally. Because in DDD an Entity is something whose lifecycle we care about. It will have to change. Audit logs are not a good example for entities, actually, I hope they're immutable. If you find yourself just modelling around data structures... maybe that's not the best place or the best angle to tackle DDD.
    – ZioBrando
    Jun 14, 2021 at 16:49
  • Thank you. I'd be curious as to where this is defined because I Googled this and didn't find a statement like the one you made.
    – Sev
    Jun 15, 2021 at 9:08
  • I think it boils down to the "Blue Book" where the Tactical Patterns are defined. Please keep in mind that the tactical patterns are not intended to be a finite set (i.e. Commands and Domain Events were not part of the original formulation), and that different tools can have different meanings for the same term. What may be an 'Entity' for your ORM isn't necessarily an Entity in DDD terms.
    – ZioBrando
    Jun 17, 2021 at 6:09

Your Answer

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

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