What happens when OOP meets Real World™

The author questions the application of object-oriented design principles, specifically encapsulation, in complex scenarios like object duplication and versioning. They recognize the importance of keeping data with behavior but struggle with deciding what object should know how to perform certain actions. The author provides an example of a Parent-Child model where the Parent should orchestrate the duplication of nested records. This raises the question of where to put orchestration logic that spans multiple objects. Three options are presented: using an orchestrator or service object pattern, making the aggregate root responsible, or delegating duplication to the nested object. Each option has pros and cons, such as keeping orchestration logic out of domain models versus accumulating coordination logic in the aggregate root. The author concludes that encapsulation is valuable, but contextual behaviors like versioning and duplication don't always belong in domain objects. These behaviors are temporal, cross-object, and may require knowledge the object shouldn't have. The solution lies in reframing what knowledge context and object are most appropriate to encapsulate. This approach acknowledges that domain entities model state and invariants, not every procedural flow, and is not a betrayal of object-oriented principles.