Bounded Contexts - Eric Evans - DDD Europe 2020

Подписаться 29 тыс.

Просмотров 75 тыс.

50% 1

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.

Наука

Опубликовано:

1 окт 2020

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 25

@davidglaubman6341 3 года назад

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

@positivity1016 Год назад

totally second it

@haotang1396 2 года назад

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.

@medic30420 Год назад

Play at 1.5 speed.

@utsavanand5558 3 года назад

Thanks for such a wonderful talk.

@algorithm-artisan 4 месяца назад

He has such good didactics, and invaluable teachings.

@balajimathu 3 года назад

Very detailed explanations on concepts..

@TheValencya 3 года назад

Wonderful!!!

@-frostyfire-5449 2 года назад

really good explanations

@yadigarcaliskan6453 3 месяца назад

Such a smart man, respect!

@kevinfleischer2049 3 года назад

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 3 года назад

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

@abdulkaderjeelani 3 года назад

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 3 года назад

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

@russellmolimock 3 года назад

@@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 2 года назад

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

@karpuzye 3 года назад

tertemiz anlatiyor reis

@Chorniyko 3 года назад

Great talk! Thanks!

@thatoneuser8600 2 года назад

26:35 Anticorruption Layer analogy

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