Bounded Contexts - Eric Evans - DDD Europe 2020

Domain-Driven Design Europe 2020
dddeurope.com - / ddd_eu
Organised by Aardling (aardling.eu/)
Bounded Contexts are a central premise in DDD. They help us to reason about a model and its language in a context, isolated from other models.
Eric Evans is the author of "Domain-Driven Design: Tackling Complexity in Software," Addison-Wesley 2004.
Since the early 1990s, he has worked on many projects developing large business systems with objects with many different approaches and many different outcomes. The book is a synthesis of that experience. It presents a system of modelling and design techniques that successful teams have used to align complex software systems with business needs and to keep projects agile as systems grow large.
Eric now leads "Domain Language", a consulting group which coaches and trains teams applying domain-driven design, helping them to make their development work more productive and more valuable to their business.

[@davidglaubman6341]

The clearest and gentlest intro to strategic DDD I have come across.

[@positivity1016]

totally second it

[@haotang1396]

A lot of respect for Eric Evans!

[@rammehar5531]

Thank you and lot of respect for Eric Evans! he did amazing work to write DDD Blue book.

[@NaeemAlsaadi]

Thanks Eric Evans for such a wonderful talk.

[@utsavanand5558]

Thanks for such a wonderful talk.

[@medic30420]

Play at 1.5 speed.

[@algorithm-artisan]

He has such good didactics, and invaluable teachings.

[@balajimathu]

Very detailed explanations on concepts..

[@TheValencya]

Wonderful!!!

[@-frostyfire-5449]

really good explanations

[@kevinfleischer2049]

Sadly he does not give a recommendation to the "reorg destroys stewardship" problem.
He points out that this is a problem. But what is the solution? Keep the stewardship as it was?
When I think about it and apply the Single Responsibility Principle as Uncle Bob explains it, than the two Contexts need to be split. Why? Because each SW component should only change for one reason. Reason = Stakeholder = Business Unit.
But this is quite an act. Just think about separating out databases. Not sure if this is realistically doable.....

[@thejacenxpress]

Agree I was looking forward to an example solution but then he just moved onto a new example

[@abdulkaderjeelani]

When te org moves to the new structure, I would prefer to freeze the old ones. In this case freeze cash and credit contexts and build 2 new contexts for business and personal. The cash and credit becomes a foundation(shared kernel) and we build on top with in the new context, no additions and deletions are to be allowed in the base contexts without mutual agreement (prefer not to do this). Then
I can continue to build the business / personal specific stuff in new contexts.
Once it starts maturing we slowly port features of shared kernel into new context and let the old contexts become thin and thin and eventually go away.
This is A LONG PROCESS !!
If we continue to live with old context forever, most cases it becomes a constraint starts to affect the value delivery.
Essentially we don't rewrite we evolve.

[@hydtechietalks3607]

@@abdulkaderjeelani Is nt that get complicated when another dimension of business change? as in more dynamic markets....

[@russellmolimock]

@@abdulkaderjeelani This is pretty similar to the solution I was expecting him to give. You create two additional layers between business cash/credit and between personal cash/credit. Have it use the language of it's new domains (business and personal), at first it's doing nothing but calling the functionality of the legacy code. Then you gradually port over feature by feature of the legacy code into this new layer, using new language and can eventually completely get rid of it.

[@BraBo]

"When I think about it and apply the Single Responsibility Principle as Uncle Bob explains it, than the two Contexts need to be split."
I think you're confusing different concepts.
SOLID is about OOP. DDD is about Domain development.
Your Bounded Context will have a shared Model, with an Ubiquitous language... But it will have several different types of objects, meant to represent your Model. Each of these objects, in OOP, should be developed using SOLID design principles.

[@yadigarcaliskan6453]

Such a smart man, respect!

[@karpuzye]

tertemiz anlatiyor reis

[@thatoneuser8600]

26:35 Anticorruption Layer analogy

[@Chorniyko]

Great talk! Thanks!

[@ytdlgandalf]

nice to see eric spelling this all out explicitly. I cringe when our software repos inside gitlab are namespaced with NetworkDept or DevDept. Your software domains should not reflect your organogram.