[inopinatus]

Abstract concepts map very well to objects. The problem of mapping a business domain to computing structures isn't unique to OOP.

In this case, I'm slightly gobsmacked that no-one pointed out that an employee is not their job. The contract of employment is a separate domain concept. So is the invocation of the clauses of that contract. Termination involves invoking a particular contract clause.

The job is to model a) the contract, b) the invocation of a specific clause, c) the record of that invocation (including its authorisations and so forth), and d) the consequential processing in other systems.

Whether you're working in FP, or Kay-style OOP, or Java-style OOP or, heck, SQL stored procedures, these are separate concerns, separate concepts, separate units of code, separate records, hopefully loosely coupled by whatever idiomatic form is at hand.

[nimblegorilla]

> Abstract concepts map very well to objects. The problem of mapping a business domain to computing structures isn't unique to OOP.

Yes, I agree in theory. What I meant to say is that many concepts don't map to physical objects.

> In this case, I'm slightly gobsmacked that no-one pointed out that an employee is not their job. The contract of employment is a separate domain concept.

This is what I mean by flamewars. Your solution sounds good, but there are other people on this same thread still arguing that it makes perfect sense for an employee to fire itself.

[inopinatus]

The litany of category and analytic blunders on display in that subthread is remarkable, but it’s hardly intrinsic to OOP, and mostly attributable to inexperience.