Designing my domain model--could use some help
Posted: Tue May 05, 2009 7:29 am
Hey guys,
I work as a web developer for a medical company, and I'm starting from scratch with this new version of the records software, and I'm really trying to do this with the best OOP principles possible. I'm in the planning phase now, and I'm trying to lay out some UML-like diagrams relating the different domain objects.
In the past, I've had a Patient class with a unique ID, and then a few other classes for SOAP notes, Transfers, History and Physicals, and they're all related with that unique ID. This works alright, but the need is arising for more control based on this ID. The format of the ID is as follows: xxx-xxxx-xxx. The first triplet represents the company, the middle quartet is a unique ID (unique within that company) and the last triplet is for the plan that they are enrolled in. So, I need methods like patientPeer::retrieveByCompany(03X), and patientPeer::retrieveByPlan(03B). Then there's a whole bunch of methods required for validation, creation of new IDs, etc.
Basically, there is tons of logic for the ID that I need to use. In the past, I've just had the ID stored as a string, and then in the controller nastily explode() it based on the hyphen. That's messy though, and all sorts of duplication results. So, I'm wondering how you'd recommend I model this.
My idea was to make a new class just for the ID. This would have four fields, one for the text string of the entire id, and then three others for each of the sections. This way I could easily have peer methods retrieving based based on any of the little sections of the ID. This presents the problem of how it would relate to my patient class. Obviously, the ID is nothing without the patient class, and vice versa. Perhaps having the Patient class inherit from the ID class? Still, not sure how that'd work--or if it's the best option.
This is probably basic stuff to you guys, so I apologize if it does not merit this forum, but I really want to do this as best as humanly possible, and as such, I figured I'd ask on here.
I work as a web developer for a medical company, and I'm starting from scratch with this new version of the records software, and I'm really trying to do this with the best OOP principles possible. I'm in the planning phase now, and I'm trying to lay out some UML-like diagrams relating the different domain objects.
In the past, I've had a Patient class with a unique ID, and then a few other classes for SOAP notes, Transfers, History and Physicals, and they're all related with that unique ID. This works alright, but the need is arising for more control based on this ID. The format of the ID is as follows: xxx-xxxx-xxx. The first triplet represents the company, the middle quartet is a unique ID (unique within that company) and the last triplet is for the plan that they are enrolled in. So, I need methods like patientPeer::retrieveByCompany(03X), and patientPeer::retrieveByPlan(03B). Then there's a whole bunch of methods required for validation, creation of new IDs, etc.
Basically, there is tons of logic for the ID that I need to use. In the past, I've just had the ID stored as a string, and then in the controller nastily explode() it based on the hyphen. That's messy though, and all sorts of duplication results. So, I'm wondering how you'd recommend I model this.
My idea was to make a new class just for the ID. This would have four fields, one for the text string of the entire id, and then three others for each of the sections. This way I could easily have peer methods retrieving based based on any of the little sections of the ID. This presents the problem of how it would relate to my patient class. Obviously, the ID is nothing without the patient class, and vice versa. Perhaps having the Patient class inherit from the ID class? Still, not sure how that'd work--or if it's the best option.
This is probably basic stuff to you guys, so I apologize if it does not merit this forum, but I really want to do this as best as humanly possible, and as such, I figured I'd ask on here.