DDD is data science for business methods ....

[Douglas Gugino]

... random thought that I had while attending ODSC Boston.  any comment?

[Aryeh]

My thought is that you don't really know what it is?

[Douglas Gugino]

you are correct - however data scientists spend 90% of their time cleaning data - getting their hands dirty, so to speak.  DDD practitioners should spend that amount of time defining business methods - and getting hands dirty learning business.  The business method is fitting business algorithms for business events (data), a few more analogies ...

[Aryeh]

My concern with your original statement, is that I believe you have a somewhat warped view of DDD.  In that your not to blame, it is increasingly common.

Your view of representing a problem in code seems to have become a functional (programming) one, which is understandable as that particularly suits CQRS/ES, and is one advocated by many proponents here.  I talked originally about this here: https://groups.google.com/forum/#!msg/dddcqrs/NIb4GZRljms/2aCfUc80NAAJ

Is DDD without a real domain model DDD?  No. That's my contention.  A real domain model is not a bunch of separate silos of logic within transactional boundaries that only coordinate through eventual consistency.  If you can't test your domain model independently of UI and persistence you don't have one.  It is something else, call it something else.

Taking one building block, "Aggregate", noting that it sort of can fit like a "Function" between a Command and an Event, doesn't make it DDD.  It is something else.  I attribute it to people wanting to be able to say - I'm doing DDD too!

[Greg Young]

"Is DDD without a real domain model DDD? No. That's my contention. A
real domain model is not a bunch of separate silos of logic within
transactional boundaries that only coordinate through eventual
consistency. If you can't test your domain model independently of UI
and persistence you don't have one. It is something else, call it
something else."

Huh?

"Taking one building block, "Aggregate", noting that it sort of can
fit like a "Function" between a Command and an Event, doesn't make it
DDD. It is something else. I attribute it to people wanting to be
able to say - I'm doing DDD too!"

Huh?

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



--
Studying for the Turing test

[Aryeh]

> Huh?

What don't you understand?

[Greg Young]

I understand the words but the meaning you have or where you came up
with it I don't understand. EG Aggregate = function? Or that you need
UI and persistence to test models? [citation needed]

[Aryeh]

> you need UI and persistence to test models

You may have read it wrong.  I said the opposite.  In fact I said, if you can't do test it independently, you do not have a real domain model.

> Aggregate = function

My contention is that is how the OP views the world.  I realize that from the original statement it's hard to work out where that comes from.  It comes from previous discussions on this list and I should have mentioned them

[Greg Young]

> you need UI and persistence to test models

I read it as implying ES based models need UI and persistence to test
and therefore are not "real domain models"

[Aryeh]

> you need UI and persistence to test models

Again, I didn't write that.

[Greg Young]

"Is DDD without a real domain model DDD? No. That's my contention. A
real domain model is not a bunch of separate silos of logic within
transactional boundaries that only coordinate through eventual
consistency. If you can't test your domain model independently of UI
and persistence you don't have one. It is something else, call it

something else.:

Maybe there is some background here I am missing

[Aryeh]

The background is largely the previous post I mentioned and the thread containing it.

https://groups.google.com/d/msg/dddcqrs/NIb4GZRljms/2aCfUc80NAAJ

[Douglas Gugino]

 the analogy is that DDD can solve the business language problem. 

https://www.opendatascience.com/conferences/odsc-east-2016-stefan-karpinski-solving-the-two-language-problem/