Thanks for the great response! I may be wrong, but it seems your design architecture is similar to “structured design”. Where you model data, and alongside tha

Thanks for the great response! I may be wrong, but it seems your design architecture is similar to “structured design”. Where you model data, and alongside that the transformations to be performed on that data. Traditionally this might have been documented using entity-relationship and dataflow diagrams. In our case, we model our complex business problem domain using an object model independent of persistence and any particular user/system interaction. Perhaps unusually for these days, we also model the many constraints (business rules) within the object model. Given that the nature of our domain model is not based on transformations that I guess are more easily quantified (or as Dijksta would say “calculated”), I’m still unsure that formal methods would apply or bring any benefits to us at large, other than perhaps some areas of specific behavior?