Looks for nouns in the problem description.

Nouns become classes, fields, and derived values. If something contains other things, it's a class; if something has a single value, it's a field. Derived values (e.g. pizza/order price in the Pizza example) should be implemented as methods (preferably getters so they can be used as properties).

Use proper types for the fields.

From the design point of view, the difference between Java primitive types (e.g. int, double, char ...) and their corresponding class types (e.g. Integer, Double, Character ...) is that class types can be null, while primitive types always have a value. Null is often useful in design as it can be used to represent conditions such as unknown, not yet available, TBD, missing, and so on. In particular, the id field of a new entity object should be null so the entity manager can handle it accordingly, e.g. using INSERT instead of UPDATE to save it. If you need to choose between primary type and class type, when in doubt, choose class type.

Use proper types for class fields. One common mistake is to use String to represent dates or timestamps - don't do that as you won't be able use many useful date functions for formatting, extracting fields, date manipulation and comparison and so on. Between the Date class and the Calendar class, you should choose Calendar if you need to perform any kind of date manipulation on the field. Use Date if you just want a timestamp and don't need to do much with it. When in doubt, use Calendar.

Focus on good OO design.

Unless you are very good with both OO and relational design (in which case you can kind of do both at the same time), you should focus on OO design first.

An example of good vs. bad OO design is the supervisor field in the Employee example. Employee supervisor is good OO design while Integer supervisorId is bad. As we discussed in the lecture, good OO design makes application development easier, e.g. you can do employee.getSupervisor().getSupervisor().getName() instead of doing complex queries.

Try to keep the design nice and simple. Obviously a design needs to be as complex as the problem requires, but don't overthink or over-design.