DC: Thinking of base library

EDIT:
Domain Components (DC) is in maintenance mode and we do not recommend its use in new software projects.

This post is one in a series about our work on Domain Components (DC) framework and related component libraries. I’m just describing what we are working on, what problems we are facing and what results we've got so far.

The new Domain Components framework will let developers create reusable domain components. Obviously, we should supply our variant of the domain component library. Our library should be full enough to let XAF developers start fast, and to provide a common well-established base for domain component developers. At the same time, it should be flexible enough to let developers replace or extend the parts that they don’t like.

I think, in the end, we will have our domain component library derived in two parts – very specific base components, which will be reused across all other components, and common domain components, which can be replaced or extended as required. Let me illustrate this approach.

Nearly every application needs information about a person. It can be just user information, or more detailed information on a customer, or very detailed information on a legal person. Obviously, there should be a base component Person, which will be referenced and reused by third-party domain components, and a real Person component, which contains more detailed information.

Components that reference the base Person don't need much information on it. So, it may contain a FullName and ShortName, and, in rare cases, Birthday and Gender:

    public interface IPersonRef {
        string FullName { get; }
        string ShortName { get; }
        DateTime? Birthday { get; }
	Gender Gender { get; set; }
    }

A real Person component may have more properties: FirstName, MiddleName and LastName, or GivenName, Surname and FatherName (depends on the culture). We should provide the Person that is sufficient in common cases – like this:

	[DomainComponent]
	public interface IPerson : IPersonRef {
		string FirstName { get; set; }
		string MiddleName { get; set; }
		string LastName { get; set; }
	}

You can use your own IPersonRef descendant in your application, instead of the IPerson. In this instance, all domain components that depend on the IPersonRef interface will work. For this purpose, we will provide a way to tell the system that "in this application the IPersonRef should be resolved into the RomanEremin.DC.General.IRussianPerson component".

Now, we are at the genesis of creating a base domain component library, and considering an approach to implement a useful one. I think we should start writing a real-world application (this has been requested for some time). While writing, we will get core, common and application-specific components that can be included in our component library.

What application should we write? I'm thinking of a generic CRM application. Most of us are intuitively familiar with applications of this type, so we won’t need to explain much, and most of us will be able to use it.

Free DevExpress Products - Get Your Copy Today