Domain Model: Domain Modeling is a way of representing the context in which the software must operate to understand the

e software better. However, one must remember that youre not modeling the software to be built! A better description would be: A Domain Model in Software Engineering can be thought of as a conceptual model of a system which describes the various entities involved in that system and their relations. Five Characteristics of a good domain model: A domain model is likely to be a good one if it
1) Models the problem domain correctly. A good domain model is not

necessarily an exact copy from the real world, but it must model the problem domain with the required accuracy. This means that it must contain only the information, which is relevant for solving the given problem. Unnecessary information must be excluded from the domain model even if it would exist in the real world. However, containing the right entities is not enough. The associations of those entities must be correct as well. The problem is that before you can judge a domain model by using these criteria, you should have some knowledge from the problem domain.
2) Speaks the right language. Because a domain model is a

representation of a problem domain, it is essential that its elements have been named correctly. This ensures that both the client and the subcontractor are speaking the same language. Speaking the same language is important because it minimizes the possibility of misunderstandings, which reduce the quality delivered to the customer. Verifying if the analyzed domain model fulfills this requirement is quite simple. If the elements of the domain model have been named correctly, your customer should be able to understand it without problems.
3) Claims ownership of its information. A good domain model

controls the changes made to its information. This means that it should provide methods for manipulating its contents and prohibit all other changes to the information under its control. Providing only a single access point to the information of a domain model has two

major advantages: it reduces duplicate code and protects the integrity of the domain model. Thus, following this guideline will lead in to cleaner and less error prone code, which should be the goal of every software engineer.
4) Provides built-in support for logging. Because it is often useful to

write the contents of an object to a log message, a domain model should provide a simple way to obtain the contents of an entity as a string. This ensures that you do not have to construct log messages manually. All you need to do is to append the object in question to a log message and you are good to go.
5) Is covered by unit tests. This characteristic of a good domain model

is kind of obvious (at least for professionals), but it is observed that assumptions can be dangerous. That is the reason why I wanted to write down a few words about unit testing a domain model. Even though I know that precise guidelines can be dangerous, I think that in this case it is possible to present an exact guideline for unit testing any domain model. You must simply test every method, which is not a getter or setter method. UML domain model UML domain model will relate objects in the system domain to each other. It will define concepts and terms. Objects in the domain model can be:

Physical objects Abstract concepts

List Objects (Concepts) To help the development of a domain model, it is important to identify nouns and noun phrases. Concepts that may not ultimately become objects may be listed for completeness and for discussion. The following types of concepts should be listed:

Actor roles Events Transactions o Transaction line items

Objects (physical) o Containers Items (in container) o Other systems o Organizations Specification concepts should be used when redundant information is reduced through their use or deleting instances of what the specification describes can result in information loss.

Nouns can be taken from the requirements definitions and use case drawings. This means at this point all your use case drawings should be done. Actors should not be emphasized in the domain model. If information from an object is derived from another object, that is reason to exclude it. However, if the object is required or is important to the use case, it should be included. Domain Model Syntax After the list of concepts is complete a domain model should be made. Consider which simple items should be attributes of objects. The domain model is a static model. Time flow, with sequence of events or information flow are not shown in the domain model. Avoid showing procedural relationships. This model does not include software. The objects in the domain model are candidates for programming objects

There can be multiple relationships between objects in the domain model. For instance an object may handle a single transaction, then make a record of all transactions it handles. In the domain model the following are shown:

Concepts (Objects) Attributes of Objects - Attributes must be simple attributes such as numbers. They cannot be objects, dimensioned numbers, or keys to part of a database. Association between objects Multiplicity Optional direction of relationship arrow Optional role of object

Associations Associations describe important relationships between concepts and may be bidirectional. Use an association to relate classes, not attributes. Some associations may be:

A is a part of B

line item of Contained inside Is a member of Is a policy of Is next to Uses Communicates with A relates to B due to a transaction

When creating associations, ask yourself, "Does one need to know about the other?". If the answer is yes, there should probably be an association. There may be more than one association between two objects. Multiplicity Describes how many instances of one concept can be associated with one instance of the related concept.

* = Zero or more 0..3 = Zero to three 2,4,6 = Two, four, or six 10 = Exactly 10 1..* = One or more 0..* = Zero or more

Advantages of the Domain Model Confining object/relational mapping logic to a clearly demarcated data access layer (DAL) within your application, facilitates the creation of a single, coherent, object-oriented Domain Model to represent your applications business objects. Adherence to this practice leads to more robust, scalable, and maintainable software. Separation of concerns Separation of concerns is a fundamental principle within computer science. As applied to an applications overall architecture, it provides for organizing a complex software system into separate, but interdependent, parts. The new apps codebase is easier to understand and maintain than the old app, thanks to the separated Data Access, Domain Model, and View Model layers. The

responsibilities of all three layers are lumped into one layer within the old app. Conceptual model. The Domain Model provides a concise representation of the domain of interest. This can aid in communication with experts in the problem domain who are not necessarily developers. Division of labor and organization of code. Need to retrieve or persist data? Then call into the DataAccess singleton. Need to execute some business logic when a conditions selected field changes? Then go to the Domain Model and put the logic into the Condition.SelectedField setter. Need to tell the View how to display itself differently? Then go to the View Model. Code Reuse. Both the old and new apps contain object-relational mapping logic. The difference is that the new apps Data Access layer, by way of generalized functions, eliminates the needless repetition found within the old apps numerous Load and Save methods. Consistent interface to in-memory data. Hiding the relational model specifics, as is accomplished by the new apps Data Access layer, provides a consistent representation of business objects. The View layer in the old app, on the other hand, contains bindings that reference both .NET properties as well as database fields. Maintainability. Because of the separation of responsibility, the new app can be modified more easily when business needs change. Changing a database fields name, for example, requires a limited maintenance effort in the new app. Since data access is coded concisely in the Data Access layer, it involves altering just one string.