Is DDD about identifying right consistency model in domain

[Shripad Agashe]

Hello,
I've been attending a DDD study group for past couple of months. We have reached till chapter 7. The more I think about it, the more I see similarities between DDD approach and database consistency models. In his video on consistency models(https://www.youtube.com/watch?v=gluIh8zd26I) , Doug Terry explained the models quite nicely.

Any thoughts on this line of thinking?

Shripad

[Keith Mifsud]

Hi Shripad,

Yes in a way it is. It is a pattern to have a consistent model but DDD is  a lot more than just that :)

The way I see it is that the biggest advantage of DDD is the communication and problem solving process and "the time this occurs" in the development life-cycle.

The Database Consistency pattern(s) only solve storage and retrieval challenges. DDD is a whole problem solving mechanism and it's damn fun :)

[Colin Yates]

I see DDD as a technical approach to modelling the business. It isn't
a _technical_ skill as much as a real-world modelling one. Database
Consistency patterns are technical solutions to problems.
Putting it another (rather trite) way:
- Real world problems
- How
- When

On 18 June 2016 at 11:58, 'Keith Mifsud' via DDD/CQRS

> --
> 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.

[Colin Yates]

Ah - accidentally clicked return too soon! Let's try again:

- the what - real world problems are identified by the business and
drive the ubiquitous language and BCs (i.e. DDD)
- the when - nothing to do with DDD but an incredibly important
question often overlooked. It does influence BCs for safety
- the high level solution - all DDD
- the low level implementation - bridge between DDD and technical patterns

Of course it isn't that simple, but I am trying to express the fact
DDD is a set of a very few tools to try and tackle the enormously
complex job of identifying and modelling the business requirements.
DDD doesn't fail due to lack of technical ability, only business
modelling ability.

[Shripad Agashe]

Sure DDD covers aspects likes UL. To me these are mechanisms to understand and communicate with business folks.

DDD indirectly talks about invariant control via boundaries. In a given bounded context, the invariants are enforced mostly using strong consistency mechanisms. Eric Brewer in his article on CAP Twelve Years Later, explains correlation of consistency and invariant quite beautifully. He says "The subtle beauty of a consistent system is that the invariants tend to hold even when the designer does not know what they are. Consequently, a wide range of reasonable invariants will work just fine. Conversely, when designers choose A, which requires restoring invariants after a partition, they must be explicit about all the invariants, which is both challenging and prone to error. At the core, this is the same concurrent updates problem that makes multithreading harder than sequential programming."

IMO DDD book also enforces this. In the Purchase order example in the book, the price of a line item to be considered for working on PO is a great example of this. The example argues that for business to work, there may be some gap in actual price vs price considered for PO. So the key idea separation of Consistency vs Freshness. Consistency models are there to enable modeling of real world scenarios. What I think has happened is that with emergence of NOSQL, the vocabulary of consistency models got richer. We are now able to express business model trade offs in consistency models like strong consistency, eventual consistency, bounded staleness and so on.

When DDD book was written this may have been one of the obstacles.

[Colin Yates]

> Sure DDD covers aspects likes UL. To me these are mechanisms to understand
> and communicate with business folks.

Exactly this. It sounded like you were challenging a point I made but
I don't see your disagreement?

I would re-articulate that DDD (for me at least) is a way of modelling
the business, consistency models aren't at all business orientated but
are a set of technical 'tools'. A subtle but very important
difference. An (exclusively) business orientated person has a chance
of effectively using DDD, an (exclusively) technically orientated
person hasn't a chance in heck. They might have the right shapes but
they will be describing the wrong thing. Of course, the ideal is that
DDD is a bridge between, and bringing closer together those two
extremes.

[Shripad Agashe]

I did not mean to disagree but elaborate my point. In fact as you see, I am in agreement about what you are saying.