A play arena contain a list of Machines and Amenities
playArena : guid : GUID name : string location: Location owner: string amenities: Amenities playing_machines: PlayingMachines Amenities is list of Amenity -> Array<Amenity> PlayingMachines is list of PlayingMachine -> Array<PlayingMachine>
Initial use case there may not be filled with too much business logic that can be assigned however with increasing application use and feedback there will be. I know its YAGNI/KISS violation however the changes are predicted in near future even though the present use case may feel as simple as CRUD application.
At present the basic use cases are
- A play arena should have at least 1 machine and amenities are optional.
- Play arena owner can update the arena, machine and amenities.
- Owner can add, update or remove the machines.
- Owner can add, update or remove the amenities.
- Owner can change other attributes for the arena.
- **Play arena have list of machines and a machine can belong to multiple play arena. Its kind of m-n relation **
These use cases don't seem too much filled with business logic and are more or less CRUD only.
How can I still use DDD and implement these changes. Should I allow add, update and deleted for machine and amenities directly with their own repository or make arena as aggregate root and pass any changes through arena repository only.
For second case :
Let's say only machine are changed do we need to still call
arenaRepo.updated(arena) -> and update all the attributes even though only machine are changed.
In first case:
I can call
getAllMachinesByArenaId(): see which are existing machine and which are new machine and directly update the database by calling the
machineRepository.save(udpatedMachines). (A kind of upsert operation)
A more practical example:
Owner wants to setup an arena (this arena may already exist or a new one) and then add machines (may exist as separate entity and associate to arena) to that arena.
Given a request DTO containing:
- An owner id
- A arena id (To check if the station exist)
- Arena details if station does not exist.
- List of machine :
- each machine also contain
- machine id or machine code if already exist (getMachineById/ getMachineByCode) enter code here
- machine with machine details if does not exist, it has to create one
UseCase can be:
AddingMachine() PlayArenaSetup() InstallingMachineToArena()
First we have to create machine through machine aggregate and then arena and then mapping arena and machine. In case any one fails do we include all three command as single unit of work or
AddingMachine() is one unit of work and PlayArenaSetup() InstallingMachineToArena() is another unit of work?