3 ms·

its a problem if you don't know your domain ... you have no business designing type hierarchies if you don't have a clue about the domain you are modeling.

• fusiongyro 14y ago
  That's kind of a cop-out, don't you think? After all, when we embark on from-scratch coding projects, we must not be perfect experts in the domain or we'd already have code we can use, right? How are we supposed to become domain experts without writing the code? Attend night classes? :) The design the author winds up with has plenty of technical debt, but it's not hard to imagine winding up there, even with partial knowledge of the domain that is constantly increasing.
• eastern2 14y ago
  The OP clearly has more than a clue about the domain. If you work in a complex domain for any length of time you realise that domains change. I don't just mean that requirements change but the actual real world domain changes. As it happens, I have been babysitting a large system in this domain since 1996. ISINs were hardly used then, and many types of derivative financial instruments hadn't been invented. Government regulations too keep changing, often bringing into existence completely new data points. 'Knowing a domain' is a meaningless concept in long-lived business system.
  • mturmon 14y ago
    "Government regulations too keep changing" Excellent point. This puts some of the comments above about how agile methods could quickly identify these problems and address them by refactoring into doubt. You could build a very big system, understanding the domain well, and then have a regulation change introduce new issues that you could not have anticipated. Beyond finance, health care would be another setting where this could be important (HIPPA must have caused a lot of hasty alterations).
• cageface 14y ago
  How do you design a type hierarchy that incorporates all future change requests? Can I borrow your crystal ball?