"Comics" Is Hard: Domain Modeling Challenges 3.82 http://spkr8.com/t/1169

Description:

It sometimes seems like all domains easily map onto relational database like MySQL and Postgres — that we live in a happy land where all Employees are People, and all People are Mammals. Unfortunately, however, there are many domains that just don't map so easily onto a standard relational schema. In this session, we'll look at three general alternatives to the familiar model, as illustrated by some specific examples.

Comments on this Talk

Stream Evan Light, 12 Jun 16:16

This user has yet to validate her/his profile with LinkedIn. It is therefore simple to assume that she/he is but a charlatan or common hoaxster. Mark as non-constructive

Presentation was entertaining. However, more than two thirds of the talk was defining the problem and less than a third outlining a handful of possible solutions. More elaborate discussion and examples of solutions may have proven more educational.

Stream ussjoin, 12 Jun 17:08

This user has yet to validate her/his profile with LinkedIn. It is therefore simple to assume that she/he is but a charlatan or common hoaxster. Mark as non-constructive

I disagree with sleight. The talk was great; a lot of the challenge in these hard domain modeling problems is deciding when to just give up on the hard schema solution and move to something more flexible. I thought the talk was well-delivered, entertaining, and informative.

Missing tmorton, 12 Jun 17:38

This user has yet to validate her/his profile with LinkedIn. It is therefore simple to assume that she/he is but a charlatan or common hoaxster. Mark as non-constructive

"Domain modeling is hard" is a great message, but I was convinced of it pretty quickly. Both examples are valuable (biology is naturally messy, comics are messy due to marketing), but I was really hoping to hear more solutions and fewer examples of the problem.

Part of the problem might be the new, shorter session length? The last 20 minutes felt rushed, and that's the section that I found most interesting.

Missing losjr, 12 Jun 20:57

This user has yet to validate her/his profile with LinkedIn. It is therefore simple to assume that she/he is but a charlatan or common hoaxster. Mark as non-constructive

I have to agree Sleight. I honestly felt most of the audience had understood the modeling issue by the time we got to the Captain America #600. I personally found the examples entertaining and informative but I also think the Civil War sucked. I think we could have used more info on the possible solutions like graph databases and document databases.

Missing losjr, 12 Jun 20:57

This user has yet to validate her/his profile with LinkedIn. It is therefore simple to assume that she/he is but a charlatan or common hoaxster. Mark as non-constructive

I have to agree Sleight. I honestly felt most of the audience had understood the modeling issue by the time we got to the Captain America #600. I personally found the examples entertaining and informative but I also think the Civil War sucked. I think we could have used more info on the possible solutions like graph databases and document databases.

Missing sotxtos, 13 Jun 15:14

This user has yet to validate her/his profile with LinkedIn. It is therefore simple to assume that she/he is but a charlatan or common hoaxster. Mark as non-constructive

The talk went way too far into the weeds of defining the problem. I would have appreciated more time spent on the solutions.

Stream Gary Fleshman, 14 Jun 12:46

This user has yet to validate her/his profile with LinkedIn. It is therefore simple to assume that she/he is but a charlatan or common hoaxster. Mark as non-constructive

Defining the problem is the problem. With that in hand, the solution is simple pitching and catching. Without a clear definition, code construction can wander endlessly.

Ben showed quite clearly that several solutions could result from each of the three example problem domains.

The presentation might have had more impact had Ben elaborated on finding the 'sweet spot' in domain modeling. There is a tradeoff between cost and benefit as the model complexity rises.

Leave a Comment

Only SpeakerRate users can comment! Log in or Register.

17 Ratings: 3.82

Delivery: 4.16

Content: 3.48

Login or register to rate this talk!

Last Five Ratings

Welcome to the SpeakerRate Beta! Have feedback? Let us know over at Get Satisfaction (but be nice).