Notes

Identifying the Core

Refactoring to segregate the core feels very risky
- Probably a lot of additional cost, without a clear cost savings
- Isn't that true for the whole thing?
- Hard to see and feel the value immediately
- Hard to see the value until you have 100% identified the core
Abstract core
- Didn't remember this part from the book, but like this
- Having a clear set of base classes means we don't have to move the core classes
- Domain model != data model
- Can a single bounded context have both core and not core in it?
  - We don't think so...
  - There are certain generic implementation details that can be abstracted away from callers
    - In that case you have supporting things that are not "core"
Are data frames and matrices in our bounded context?
Can we think of a concrete example?
- Course discovery is a domain
- Search is a bounded context
- What about the ORM for elastic search?
  - No - we wouldn't even talk about this
They seem to indicate that whole domains are either core, supporting or generic

...