Business process modelling/system theory

[Miroslav Trninić]

As I progress with my ddd/event sourcing/cqrs learning I notice that many concepts are related to general things like process modelling, system theory and even algorithm thinking. 

For example I consider aggregates to be reflection (or implementation) of business process.

Aggregates have:

• input (you can communicate with them)
  
• rules (invariants or business rules)
  
• output (aggregate state)
  
• behavior 
  
• environment (context)

It makes my learning much easier when I think about whole ddd topic like this, and not from programming perspective. Also I have 10 years of experience in "real life" jobs as CEO (before my IT career begins) and it is more easy to understand what it means "business" in the context of ddd. 

What is your opinion ?

Thanks

[Rickard Öberg]

Hi Miroslav!

I use the same approach. Starting from systems and process theory
(every process has input, output, context, transformation), and then
apply it to technical specific processes, such as aggregates within
CQRS/Event Sourcing/DDD. It helps immensely to have a clear structure
where I can slot in the specifics, knowing that these are the slots
available conceptually.

The only difference I would have compared to your description is that
output of aggregates are events, not state. These events can then be
converted to either commands for other aggregates, or read models for
queries, as needed.

/Rickard

> --
> 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.
> Visit this group at https://groups.google.com/group/dddcqrs.
> For more options, visit https://groups.google.com/d/optout.

[Miroslav Trninić]

Hi Rickard,

My understanding is that events are just one way to capture aggregate state (mostly using even sourcing). But we can have aggregates without events. For example value objects that carries aggregate state can be attached to aggregate by using factory method.

[Rickard Öberg]

2017-11-12 17:02 GMT+08:00 Miroslav Trninić <miroslav...@gmail.com>:
> My understanding is that events are just one way to capture aggregate state
> (mostly using even sourcing). But we can have aggregates without events. For
> example value objects that carries aggregate state can be attached to
> aggregate by using factory method.

Sure, but that's just another way to produce events, and it's more
complex. Let me outline a few different ways to slice this:
* with pure eventsourcing, when an aggregate receives a command you
build up current state by replaying past events. Process command,
output is events.
* in my case, when an aggregate comes in I load current state (ONLY
state needed to make decisions, not the full possible state) from read
model into a value object and attach it to the aggregate. Process
command, output is events (which update the read model so the load
works)
* in a CQRS, non eventsourcing case, when an aggregate receives a
command you load current state from the database read model. Process
command, output is either:
1) events, use them immediately to update read model, then throw events away
2) updated value state. Some process has to figure out the diff and
apply to read model (this is still events, just automated), or you
have to update the entire value into the database (this is the worst
option in my view)

Of all the possible options I would consider CQRS option 2) to be the
most complex and least useful. CQRS option 1) is the most
straightforward if you don't want to add an event store to your
infrastructure, and just stick to regular database as infrastructure.

Makes sense?

In any case, these are details compared your observation that we can
apply process and systems theory to this field, which is the important
point.

/Rickard