We are currently trying to create an application with DDD.It's my first time doing this, so I've been stumbling a lot, but I have a question about the subject.
With DDD, it is understood that states are maintained using a repository.
I'm worried about how to implement an in-memory repository (on-memory repository?) if I need to temporarily save it in memory without using DB.
Basically, I think the target that you save and retrieve in the repository is the aggregate route, but I think the aggregate route is the reference type.
If implemented in a straightforward manner, the reference type will remain intact in the repository, eliminating the need for object reconstruction during retrieval (or beyond reconstruction).
In this case, if you change the state of the retrieved object, the object is changed directly to retrieve the object by reference type.
In the examples that appear on the web or in IDDD books, the repository is often referred to as , which allows it to be handled like a collection.This means that the repository is updated only when you call an explicit API, such as Add or Update.
Therefore, I feel uncomfortable that the above direct changes are reflected.
So what is the best way to implement aggregate routes in memory?
I'd appreciate it if you could help me.Thank you for your cooperation.
In my case, I mainly use the in-memory repository for testing purposes, so if there is no particular inconvenience, I put the entity reference directly into the in-memory repository.
If this does not work, implement the in-memory repository so that deep copy works for storing in-memory repository and retrieving Entity from in-memory repository.
Alternatively, if there is a serialization process in a repository for applications other than in-memory (for example, storing json in KVS), you may follow suit to implement the in-memory repository.
Also, implementing an in-memory repository for all repositories just for testing is tedious, so you may not create an in-memory repository by devising it in your test environment (for example, always starting MySQL or redis during testing).
I've never used the in-memory repository for anything other than testing purposes, and I can't think of much of a use for it, but the implementation policy is likely to be similar to what I wrote above.
© 2024 OneMinuteCode. All rights reserved.