Domain Class Diagram

---

Your users work with objects all the time. They talk about the objects and their relationships in their domain, which is a fancy term for the group of objects that your users deal with. The insurance domain has objects such as policy, policyholder, claim, coverage, covered item, and hazard. Finance has its own domain language, including items such as equity, fund, portfolio, account, and trade. To build a system or a software application that your users understand, we recommend that you capture the language of the user in a class diagram that we like to call the domain class diagram.

If you take a look at the applications that you build, you find some of the same classes in each application. If you work in the insurance domain (for example), you need a policy class for applications such as policy generation, underwriter review, claims handling, and premium billing. You can also use the domain class diagram to define specialized terms and other user jargon. That’s because there’s one thing that computers can’t handle—vagueness. Every term, class, attribute, operation, and association must be nailed down—precisely.

 Remember   A domain class diagram must accomplish the following:

• Precisely define user terminology

• Provide common classes that are useful in many different applications

• Allow you to work with users to understand how they structure the world

So take the time to build a class diagram that accurately reflects what your users mean when they talk about their “domain.”

 Tip   Start building a domain class diagram early in your project. We begin our own domain diagrams at the same time that we’re working with users to develop use cases.

---