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.....
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.
@@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.
"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.
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.
The clearest and gentlest intro to strategic DDD I have come across.
totally second it
A lot of respect for Eric Evans!
Thank you and lot of respect for Eric Evans! he did amazing work to write DDD Blue book.
He has such good didactics, and invaluable teachings.
Thanks Eric Evans for such a wonderful talk.
26:35 Anticorruption Layer analogy
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.....
Agree I was looking forward to an example solution but then he just moved onto a new example
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.
@@abdulkaderjeelani Is nt that get complicated when another dimension of business change? as in more dynamic markets....
@@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.
"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.
Play at 1.5 speed.
Such a smart man, respect!
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.
Thanks for such a wonderful talk.
Very detailed explanations on concepts..
really good explanations
Wonderful!!!
Great talk! Thanks!
tertemiz anlatiyor reis