The CaveatEmptor domain model in C#

Printer Code 39 Full ASCII in C# The CaveatEmptor domain model

The CaveatEmptor site auctions many different kinds of items, from electronic equipment to airline tickets. Auctions proceed according to the English auction model: users continue to place bids on an item until the bid period for that item expires, and the highest bidder wins. In any store, goods are categorized by type and grouped with similar goods into sections and onto shelves. Your auction catalog requires some kind of hierarchy of item categories. A buyer may browse these categories or arbitrarily search by category and item attributes. Lists of items appear in the category browser and search-result screens. Selecting an item from a list takes the buyer to an item-detail view. An auction consists of a sequence of bids. One particular bid is the winning bid. User details include name, login, address, email address, and billing information. A web of trust is an essential feature of an online auction site. The web of trust allows users to build a reputation for trustworthiness (or untrustworthiness). Buyers may create comments about sellers (and vice versa), and the comments are visible to all other users. A high-level overview of the domain model is shown in figure 3.2. Let s briefly discuss some interesting features of this model.

Name : string Description : string InitialPrice : double ReservePrice : double StartDate : DateTime EndDate : DateTime Created : DateTime

Firstname : string Lastname : string Username : string Password : string Email : string Ranking : int Created : DateTime

Each item may be auctioned only once, so you don t need to make Item distinct from the Auction entities. Instead, you have a single auction item entity named Item. Bid is associated directly with Item. Users can write Comments about other users only in the context of an auction; hence the association between Item and Comment. The Address information of a User is modeled as a separate class, even though the User may have only one Address. You do let the user have multiple BillingDetails. The various billing strategies are represented as subclasses of an abstract class (allowing future extension). A Category may be nested inside another Category. This is expressed by a recursive association from the Category entity to itself. Note that a single Category may have multiple child categories, but at most one parent category. Each Item belongs to at least one Category. The entities in a domain model should encapsulate state and behavior. For example, the User entity should define the name and address of a customer and the logic required to calculate the shipping costs for items (to this particular customer). This domain model is a rich object model, with complex associations, interactions, and inheritance relationships. An interesting and detailed discussion of object-oriented techniques for working with domain models can be found in Patterns of Enterprise Application Architecture [Fowler 2003] or Domain-Driven Design [Evans 2004]. In this book, we don t have much to say about business rules or the behavior of the domain model. This isn t because we consider them unimportant concerns; rather, they re mostly orthogonal to the problem of persistence. It s the state of your entities that is persistent. So we concentrate our discussion on how to best represent state in your domain model, not on how to represent behavior. For example, in this book, we aren t interested in how tax for sold items is calculated or how the system might approve a new user account. We re more interested in how the relationship between users and the items they sell is represented and made persistent. Now that you have a domain model, the next step is to implement it in C#. Let s look at some of the things you need to consider.