How should you explain Design Patterns to people outside of Software World

What you describe is called Active Record pattern. See the article and google for it, then you'll find sample implementations which you can adapt for your scenario. It is basically a Repository pattern implemented in the entity itself.

Active Record is strong in some scenarios, it's the default for Ruby on Rails applications iirc, but it does have its downsides. I suggest you look them up and think about it again. Maybe your domain suits a classical domain model with persistence ignorance (like Hibernate offers) better.

See also this website here for a comparison.

When I was a novice programmer, I loved design patterns. I didn't just use design patterns. I inflicted them. Wherever and whenever I could. I was merciless. Aha! Observer pattern! Take that! Use a listener! Proxy! AbstractFactory! Why use one layer of abstraction when five will do? I've spoken to many experienced programmers and found that just about everyone who reads the GoF Book goes through this stage.

Novice programmers don't use design patterns. They abuse design patterns.

More recently, I find that keeping principles like the Single Responsibility Principle in mind, and writing tests first, help the patterns to emerge in a more pragmatic way. When I recognise the patterns, I can continue to progress them more easily. I recognise them, but I no longer try to force them on code. If a Visitor pattern emerges it's probably because I've refactored out duplication, not because I thought ahead of time about the similarities of rendering a tree versus adding up its values.

Experienced programmers don't use design patterns. Design patterns use them.