Vikas Gupta: Software architect

Archive for December, 2009

Domain Driven Design : Querying Domain Objects

Posted by Vikas Gupta on December 30, 2009

After having discussed about object creation in the previous post, I would like to discuss the challenges of querying objects in a domain model.

There is a well designed domain model with a rich set of associations between objects. How to get to a particular entity or value object inside the domain model? Since the domain model is well connected, if you have a reference to a root entity, you can get to the other members to which this root is associated. But, how to get to this root? Well, we can have a global root which contains the collections of all the root of the entities. For example, in a sales order application, you can have a global root containing the collection of order and customer objects.

One drawback of the above solution is that it will perform badly in a distributed system. For example, when a client asks the global root to return the list of customers, and there are millions of customers, we have to do a database query and it will return millions of records. This will cause a lot of data transfer on the network. With multiple clients, this solutions would not work at all.

In most situations, you would need only a subset of customers which meet a particular set of conditions. So, what are the options that we have to return a subset of customers to the client in a way which performs well and does swamp the domain model with the complexity of the query logic. The options that we have are Read the rest of this entry »

Advertisements

Posted in DDD, Design Patterns, EA Patterns | Tagged: , , , | 4 Comments »

Domain Driven Design : Creating Domain Objects

Posted by Vikas Gupta on December 21, 2009

In one of the previous posts, I discussed about Aggregates and their design considerations. In this part of the series, I will discuss the issues in object creation with domain objects.

The normal way of creating an object by it’s client is via it’s public constructor. This works well with a simple objects. But, when complex objects like Aggregates are concerned, their construction can be complex and the process of creation can become overwhelming for an object to handle. As part of it’s construction, an aggregate might have to

  • create local entities within an aggregate.
  • check the invariant logic before adding a local entity.

Object creation has nothing to do with the domain. Moreover, with complex object creation, an object tends break the Single Responsibility Principle(SRP). So, it is recommended to separate the object creation logic from the object. In Domain Driven Design(DDD), a program element whose primarily responsibility is to create complex domain objects and aggregates is called a Factory. Ideally, a factory should create the product atomically with all the safety checks, that is, with the all the invariants applied appropriately. Read the rest of this entry »

Posted in DDD, Design Patterns, EA Patterns | Tagged: , , , | 2 Comments »

Domain Driven Design : Aggregates

Posted by Vikas Gupta on December 14, 2009

Every object has a lifecycle. Some objects take birth and die in a single method while others have a more complex and longer life. Typically, Domain Objects falls into the second category. The lifecycle of a domain object is shown below

As the lifecycle of a domain model is complex, it is advisable to separate the domain logic from the lifecycle management logic. Furthermore, sometimes, grouping related objects to manage them as an entity is easier than managing each of them separately. Domain Driven Design(DDD) suggests to group related objects as Aggregates and to use Factories and Repositories to manage the lifecycle of the object. In this blog, I will discuss about the Aggregates and their design considerations. Read the rest of this entry »

Posted in DDD, Design Patterns, EA Patterns | Tagged: , , | 2 Comments »

Domain Driven Design : Expressing Concepts

Posted by Vikas Gupta on December 8, 2009

Object oriented analysis and design(OOAD) is essentially an activity to model a system as an interaction between objects. Each object, which is an instance of a class and has state and behaviour, represents an entity with in the system. These entities invoke other entities to perform certain activities and are often associated with each other to model a system. Domain driven design(DDD) recommends guidelines which tend to optimize/enhance the process of identifying entities and defining relationship between them. It advocates to classify objects as Entities and Value objects based on certain criteria, to model Services, which abstract behaviour which is not specific to a particular entity, to divide application into Modules, and to minimize and constrain Associations between objects. In this blog, I will discuss these recommendations.
Read the rest of this entry »

Posted in DDD, Design Patterns, EA Patterns | Tagged: , , , | 2 Comments »

Domain Driven Design : An Introduction

Posted by Vikas Gupta on December 1, 2009

Introduction

The primary purpose of most software projects is to add value to the customer’s business. This is done by abstracting the complex web of thoughts inside a human mind in the form of a software program. Most software projects cater to a particular domain, and in many software projects, the domain of a software project is not technical. Unfortunately, majority of the technical people do not give enough importance to the domain of the software, and hence, they lack the required domain knowledge. This lack of domain knowledge leads to a situation where What(to do?) takes over Why(to do?). Generally, in such a scenario, it might be possible to deliver a usable product, but the primary purpose of adding business value is often neglected.

The above mentioned situation is quite common and there is a continual influx of thoughts, which intend to provide a solution, by various experts. Eric Evans is one of such experts, who based on his experience, gained by working on complex projects, epitomized his findings in the form of tips, suggestions, patterns and guidelines, and coined a term Domain Driven Design, better known as DDD. In this blog, I intend to present various aspects of DDD and how it suggests to tackle the complexity of the domain.
Read the rest of this entry »

Posted in DDD, Design Patterns, EA Patterns | Tagged: , , , | 3 Comments »