Let's take an example (from an old exam, actually, but that is besides the point):

Dash

(1) Dash is a tool to quickly and easily transfer money to friends and to pay for things using your mobile phone. It is developed in collaboration with a collection of Swedish banks. In this description we focus on what you can do with the application once it is installed Dash on your phone and connected it with your bank account, and that you have BankID installed and configured. Your task is to design the features of the system that are described below.

(2) With Dash you can transfer money to other Dash users, receive money, and view a list of previous transactions.

(3) You transfer money by entering the mobile phone number of the recipient, the amount you want to transfer, and a message.

(4) In order to actually execute the transaction you identify yourself using your BankID. This starts a transfer of the specified amount from your account to the bank and account associated with the recipient's mobile phone number.

(5) At any point, you can abort a transaction.

(6) If there is not enough money in our account to complete the transaction, the transfer is aborted.

(7) If you want to see if you have received any money you first identify yourself yourself using your BankID. The Dash app then displays the last transaction, including the sender of the money, the amount received, and the message.

(8) You can get an overview of all transactions. You first have to identify yourself using your BankID, and then the Dash app displays an overview of previous transactions. This includes both incoming and outgoing transactions.

(9) To identify yourself using BankID, you enter a pin code. The system then connects to the BankID server to verify your identity.

(10) If you enter the wrong pin code, the current operation is aborted.

Ok. So where do we start? A good starting point is to look for nouns. All nouns represent either concepts, or attributes of those concepts (For example, a name might be an attribute of a person). There is no easy way to decide what should be a concept and what should be an attribute, since this is very much context dependent. But don't worry: the idea of the domain model is for you to understand the problem domain, and you are not expected to get everything right directly. You can always go back and change the model later. And I mean always. Sometimes you learn new things as late as when the customers are busy doing acceptance testing that suggests you should go back and edit your domain model.

The nouns in the Dash description are (in order of appearance):

Money
Mobile Phone
Bank
BankID (this is technically not a noun but can, for the sake of this system be treated as if it was. If you really want a noun, try AuthenticationService instead)
Mobile Phone Number
Amount
Message
Transaction
BankAccount
Sender
Receiver (not in the description, but since we have sender, it is a fair assumption that someone will receive the money)
TransactionOverview
IncomingTransaction
OutgoingTransaction
Pin Code
BankID Server
Identity

... and that's it! Let's model this. At the core of this system are Transactions, so I'll start there. Each transaction has a message and an amount. Let's put these as attributes for now, since they do not have a meaningful existence outside of a particular transaction. A transaction also has a sender and a receiver, which I am going to model as concepts since they can exist outside of a particular transaction:

(Cave: This will change pretty soon. I include it here to illustrate precisely that point: Creating a domain model is an iterative process where you will continuously revise the output)

Next, let's look at the Sender and Receiver. They both have a PhoneNumber, a BankAccount at a particular Bank, and an Identity at BankID. In fact, the only thing separating them are the roles they have in a particular transaction. So let's merge them into one concept: Customer:

dm2

A few things happened here. We described the roles of customer on the lines -- the relations, or associations -- between the concepts Transaction and Customer.

We also decided that Identity was something important enough to keep it as a separate concept rather than an attribute of a Customer. The reason for this is primarily that the identity involves two parties, Customer and BankID, which makes it difficult to model as an attribute. An attribute should be something which the concept has sole possession and care of (You are right. PhoneNumber is something between the phone company and the customer too, but that is outside of the problem domain for the Dash app, so we can happily ignore this).

In the same way we decided that BankAccount, involving both the Customer and the Bank, was a separate concept.

The remaining nouns are:

Money: We deal with money in terms of "Amount", so we can skip this.
Mobile Phone: This is the device through which we access the problem domain, but is not really part of the problem domain itself.
BankID Server: Since we are not modelling how the BankId application is working, we have no need to know that there is a server involved there. This is outside of our problem domain.
TransactionOverview, IncomingTransaction, OutgoingTransaction: Whether a transaction is incoming or outgoing can be determined by whether the customer is linked as a Sender or as a Receiver, so we already have this information. What remains is the TransactionOverview. Let's put that in.

dm3

... and there you have it. The Supreme Initial Rough Draft Domain Model of the Dash App. To make it easier to read, I've added descriptions to all the associations so that you know their function. I've also added directional arrows to most of them, which makes it easier to know who is the "owner" of the association.

Note the absence of functionality here. It is only the domain concepts and their relations that are modelled. Also note that If you read the description again you will realise that BankAccount also needs an amount to be able to implement paragraph (6). I am sure there are other things I've missed as well, but I can always go back and add them later.

Now, let's raise our eyes a bit and see what we can do and cannot do with the help of this beautiful domain model. Click "Next" below and find out.