https://www.youtube.com/watch?v=g0Eoe1DfFPE
At 1:00 #term-strategic-ddd versus #term-tactical-ddd, which he also calls #term-ddd-light
At 4:21 in Rails, often the create or update can have multiple domain services.
At 4:55 in #term-strategic-ddd #term-bounded-contexts he sometimes calls them #term-module.
At 5:08 there is a diagram from Martin Fowler from article-bounded-context-martin-fowler
At 5:45 you can think of a #term-bounded-context as being like a department at a company. Often they map 1:1.
At 8:45 How to keep multiple services up when one service is down. By duplicating the data. This sounds a bit like talk-silence-is-golden, but in that case, the data duplication was specifically for keeping services available. Here that seems to be one of the side-effects.
At 9:10 One #term-module (AKA #term-bounded-context) does not look at another modules database tables.
At 11 not all of those bounded contacts are deserving of #term-ddd-light. Some of them can be done in the standard way. It depends on the complexity of what is being accomplished within the bounded context. Also, if you have a legacy system, some of the contexts might be better candidates to work on first (higher value).
video-from-legacy-to-ddd#escape-from-the-crud-verbs1 At 14:08 Escape from the CRUD verbs video-from-legacy-to-ddd#escape-from-the-crud-verbs1
video-from-legacy-to-ddd#words-the-business-people-use1 2 At 14:35 the words the business people use video-from-legacy-to-ddd#words-the-business-people-use1 2
At 16 even if you have really good speed of work regressions will break customer trust because customers don't understand how things get broken
At 19, if you view the bounded contacts as the unit in testing-concept-test-units-not-classes, then you can move from CRUD to DDD without the test breaking, for example.
video-from-legacy-to-ddd#do-not-use-params-hashes1 At 22:30 don't pass the params/hash everywhere. Some people call the wrapping of that data form-objects. video-from-legacy-to-ddd#do-not-use-params-hashes1
At 23:45 An infinite API. video-from-legacy-to-ddd#call-high-level-apis1Call the high-level API, and not the models directly. video-from-legacy-to-ddd#call-high-level-apis1 (This sounds a lot like calling the API in a well-defined subsystem or code-neighborhoods
At 24:15 use events to communicate between bounded contexts.
video-from-legacy-to-ddd#easy-to-introduce-events-in-same-database Easy to introduce events when in the same database. video-from-legacy-to-ddd#easy-to-introduce-events-in-same-database
At 25:42 to start with he says to use sync as opposed to async.
At 26:57 use CQRS to separate reads and writes. For reads you can continue to use ActiveRecord.
video-from-legacy-to-ddd#duplicate-the-data At 28 do not query the data from other bounded contexts. Duplicate the data in the bounded context. video-from-legacy-to-ddd#duplicate-the-data
At 29 bounded contexts ease testing
At 29:20 read-models for query data and handling events
In a way it's like a cache. It can be reconstituted from the events. It is denormalized.
At 31:30 treat your front end as a bounded context
At 32:30 always be thinking in terms of aggregates
At 32:45 event-source-system
At 34:30 distributed transactions are tricky, but a bounded context makes a great candidate for a microservice eventually. However, to start, use a single database.
Bounded contexts seem a bit like highly cohesive and extremely loosely coupled subsystems with a clearly defined communication pattern (events only). Much like microservices, not reading each-other's data directly is a critical part of ensuring their separation.