Commands, CRUD or CRUD commands?

[Alexey Raga]

Hello,

I am entertaining this toy example for getting a better understanding / simpler solution for a common pattern.

Let's say that we doing DDD, perhaps CQRS, but not EventSourcing.

Assume that there is a Task that is assigned to a group of Students to perform. The Task has a deadline, and each Student has, say, 2 attempts to make.

My question is:

There is a bunch of information about Task that doesn't trigger any business logic, but is (or may) affecting the UI side.

For example, Task Title, a "hints enabled" flag, etc.

Would you still model them as commands/events even given that these commands don't trigger any business logic?

RenameTask / TaskRenamed, EnableHints / HintsEnabled, EnableReferences / ReferencesEnabled and other many like that? (EventSourcing is not involved)

Or would you somehow CRUD this data and only model "real" business logic via aggregates/commands/events?

How would you deal with the view side in this case?

[Harrison Brown]

Both are options. It depends, I think, in how cohesive the information is and how many hoops you have to junk through to separate things. For you example, I might keep those things in the aggregate but treat them as a blob of data that’s not really exposed to the domain model (meaning it doesn’t obscure the important stuff) by making a TaskDetails value object (name it better, obviously) and storing it as JSON in the database and events. I’d then have events like TaskDetailsUpdated.

In other cases you can entitle separate out things if they’re sufficiently separate. I recently had an app where we needed to show a set of aggregates as boxes in a dashboard, each with a picture and description, and in a certain order with users being able to drag and drop them into different a order. There, we separated out information like image, description, dashboardLocation, etc. into a separate aggregate — something like DashboardEntry($aggregateId, $image, …) — and modelled it with active record outside of the domain model. That worked well because one can usefully think about and do something valuable with DashboardEntry without also having to look inside the aggregate it’s showing. That’s what I mean about cohesive.

Harrison

Sent from my iPhone

On 10 Aug 2021, at 00:46, Alexey Raga <alexe...@gmail.com> wrote:

Hello,

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/7d89f3be-5575-4359-9888-5ec9aaad244an%40googlegroups.com.

[Mateusz Nowak]

Yes, exactly as Harrison said. 
Its good idea to separate part with business logic and rich model from CRUD actions with are focused on database. 
In this repository you can find differences (and examples) between Complex Commands / Complex Queries and Simple CRUD: 
https://github.com/ddd-by-examples/factory