Method Signature Patterns

The most typical pointcut expressions are used to match a number of methods by their signatures. A common method based pointcut expression is something like

expression(<method scope> <return type> <fully qualified class name>.*(parametes))

1. method scope: Advice will be applied to all the methods having this scope. For e.g., public, private, etc. Please note that Spring AOP only supports advising public methods.
2. return type: Advice will be applied to all the methods having this return type.
3. fully qualified class name: Advice will be applied to all the methods of this type. If the class and advice are in the same package then package name is not required
4. parameters: You can also filter the method names based on the types. Two dots(..) means any number and type of parameters.

Examples

• execution(* com.aspects.pointcut.DemoClass.*(..)) : This advice will be applied to all the methods of DemoClass.
• execution(* DemoClass.*(..)): You can omit the package if the DemoClass and the advice is in the same package.
• execution(public * DemoClass.*(..)): This advice will be applied to the public methods of DemoClass.
• execution(public int DemoClass.*(..)): This advice will be applied to the public methods of DemoClass and returning an int.
• execution(public int DemoClass.*(int, ..)): This advice will be applied to the public methods of DemoClass and returning an int and having first parameter as int.
• execution(public int DemoClass.*(int, int)): This advice will be applied to the public methods of DemoClass and returning an int and having both parameters as int.

Type Signature Patterns

These pointcut expressions are applied to all joinpoint of certain types. A common type signature patterns looks like

within(type name)  

Here type name is either the package name or the class name.

Examples

• within(com.aspects.blog.package.*) : This will match all the methods in all classes of com.aspects.blog.package.
• within(com.aspects.blog.package..*) : This will match all the methods in all classes of com.aspects.blog.package and its sub packages. The only difference is the extra dot(.) after package.
• within(com.aspects.blog.package.DemoClass) : This will match all the methods in the DemoClass.
• within(DemoClass) : Again, if the target class is located in the same package as this aspect, the package name can be omitted.
• within(DemoInterface+) : This will match all the methods which are in classes which implement DemoInterface.

Bean Name Patterns

Spring 2.5 supports a new pointcut type that is used to match bean names. For example, the following pointcut expression matches beans whose name ends with Service.

bean(*Service) 

This pointcut is not supported by AspectJ annotation, hence you can declare them only in spring context files.

Combining Pointcut Expressions

Pointcut expressions can be combined using && (and), ||(or), and !(not). For example,

within(DemoInterface1+) || within(DemoInterface2+)

The above patterns will match all join point in all classes which implement DemoInterface1 or DemoInterface2

Declaring Pointcut Parameters

One way to access join point information is by reflection (i.e., via an argument of type org.aspectj.lang.JoinPoint in the advice method). Besides, you can access join point information in a declarative way by using some kinds of special pointcut expressions. For example,

@Aspect
public class SomeAspect {

  @Before("execution(* *.*(..)) && target(target) && args(a,b)")
  public void someMethod(Object target, int a, int b) {
    log.info("Target class : " + target.getClass().getName());
    log.info("Arguments : " + a + ", " + b);
  }
}

Here, target captures the target object and args captures the parameters.

Applying arbitrary patterns

Although the syntax of the AspectJ pointcut expressions is pretty rich, you may find some scenarios in which they are not sufficient to provide the necessary behaviour. In such scenarios, you may choose to create an annotation and use that to match joinpoints. This is done in the following manner

First create an annotation

@Target(ElementType.Method)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @Interface ApplyAspect {
}

Once you have created this annotation, you can created pointcut expressions like

@annotation(ApplyAspect)

This will match those methods which are annotated with @ApplyAspect. You can also apply this to classes, for example

@within(ApplyAspect)

This will match all joinpoints in classes annotated with @ApplyAspect.

Conclusion

In this blog, I have discussed the expressions for AspectJ pointcuts, which are powerful mechanism to filter the joinpoints.

Sometimes small details of the design get lost in the code. We tend to consider small business rules and constraints as implicit and these details are not given enough importance as they should be given.They are often coded as a bunch of if-else blocks in the code and this makes the identification of these business rules difficult and more importantly makes design less effective. Let see some of the concepts/design patterns which can be used to make these implicit concepts more explicit.

Specification

Most application have small rules which are evaluated as boolean value. Some of these can be simple. But, there are certain rules which are fairly complex. They are infact, a combination of one or more of such smaller business rules. Sometimes, these rules are applicable on multiple objects and can be complex enough to make their prescence felt and it is advisable to factor them out in a separate class or method. Such business rules can be termed as Specification as test any object to see whether it satisfies the specified criteria. Let’s see the example of a specification.

class OverdueInvoiceSpecification extends InvoiceSpecification {
   private Date currentDate;

   public OverdueInvoiceSpecification(Date currentDate) {
      this.currentDate = currentDate;
   }

   public boolean isSatisfiedBy(Invoice invoice) {
      int gracePeriod = invoice.customer().getPaymentGracePeriod();
      Date deadline = invoice.dueDate() + gracePeriod;

      return currentDate.after(deadline);
   }
}

Now, we can simply apply the rules wherever, we want

class CustomerAccount {
  boolean isOverDue() {
   Specification overDueSpec = new OverdueInvoiceSpecification(new Date());
   Iterator<Invoice> listInvoices = customer.getInvoices().iterator();
   for (Invoice invoice : listInvoices) {
     if (overDueSpec.isSatisfiedBy(invoice)) return true;
   }
   return false;
  }
}

There can be many places which warrant the use of specification pattern in an application. Mostly, they are used in

• Validations, as demonstrated above
• In filtering data, based on business rules. For doing this we can combine Repositories with Specifications and filter data returned from the persistent storage
• In domain object security. We can check using specification whether a particular object is editable by a user with specified role. Spring security provides a more sophisticated framework for this.

There is no doubt that factoring out methods and classes for these business rules makes design more expressive, but, there can be numerous such rules in the code and factoring a separate places for each of them can be quite cumbersome. So, how to decide when to create a new method or class for a business rule or constraint.  I think the key lies in the word business. If a condition affects a business decision, it is a business rule and we can model them separately in a method or class. Moreover, if the specification code in itself is bit involved and can be applied as multiple places, it is better to separate them out of the domain object.

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

• Using a SQL query
• Query Objects
• Repository Objects

Let’s look at these options in detail.

Using an SQL query

An SQL query is a powerful tool to get what we want from the database. Using an SQL query involves processing the resultset returned from the database and converting into object format. This data access code if coded inside the domain objects can result in obfuscating the domain model. Also, there is a tight coupling between domain objects and database.

This problem of translating between object world and the database world can partially be solved by using metadata mapping. Meta data mapping reduces the overhead of translating between java objects and sql resultsets. But, the problem of separating data access code from the domain model is still there if sql queries are employed.

Query Objects

A Query Object is a structure of objects that can form itself into a SQL query. You can create this query by referring to classes and fields rather than tables and columns. In this way those who write the queries can do so independently of the database schema and changes to the schema can be localized in a single place. A Query object is based on Interpreter pattern. Hibernate, a leading framework for Object Relational mapping provides API for query Objects. Following is an example of data Access Code written using query objects

List cats = sess.createCriteria(Cat.class)
    .add( Restrictions.like("name", "Fritz%") )
    .add( Restrictions.between("weight", minWeight, maxWeight) )
    .list();

The advantages of Query Object come with more sophisticated needs: keeping database schemas encapsulated, supporting multiple databases, supporting multiple schemas, and optimizing to avoid multiple queries. Some projects with a particularly sophisticated data source team might want to build these capabilities themselves, but most people who use Query Object do so with a tool. There are a lot of tools available like Hibernate, Toplink, iBatis which provide APIs for creating queries using object oriented code.

Repository Objects

Query Objects help in cleaning up the domain model from the data access code. But, in most scenarios, it is advisable to separate the data access code from the domain model into a separate layer. A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection.

Repository presents a simple interface. Clients create a criteria object specifying the characteristics of the objects they want returned from a query. For example, to find person objects by name we first create a criteria object, setting each individual criterion like so: criteria.equals(Person.LAST_NAME, “Gupta”), and criteria.like(Person.FIRST_NAME, “V”). Then we invoke repository.matching(criteria) to return a list of domain objects representing people with the last name Gupta and a first name starting with V. Under the covers, Repository combines Metadata Mapping with a Query Object to automatically generate SQL code from the criteria. An example involving repository is shown below

public class Person { //domain object
   public List dependents() {
      return Registry.personRepository().dependentsOf(this);
   }
}

public class PersonRepository extends Repository {
   public List dependentsOf(aPerson) {
      Criteria criteria = new Criteria();
      criteria.equal(Person.parent, aPerson);
      return matching(criteria);
   }
}

abstract class Repository {
   private RepositoryStrategy strategy;
   protected List matching(aCriteria) {
      return strategy.matching(aCriteria);
   }
}

public class RelationalStrategy implements RepositoryStrategy {
   protected List matching(Criteria criteria) {
      Query query = new Query(myDomainObjectClass())
      query.addCriteria(criteria);
      return query.execute();
   }
}

Because Repository’s interface shields the domain layer from awareness of the data source, we can refactor the implementation of the querying code inside the Repository without changing any calls from clients. Indeed, the domain code needn’t care about the source or destination of domain objects. In we want to change the data to be picked up from the memory instead of the database, we can simply change the RepositoryStrategy from relational to in memory by creating an in memory relational strategy.

After having discussed about various methods of querying the domain objects, we can conclude that on a large project with complex domain we should not use queries directly from the domain model. Now, as far as query objects and repositories are concerned, I think they both resolve a separate problem. Query Objects help in abstracting the data access code in an object oriented way, whereas, Repository is used for separating the data access code from the query objects and providing for additional sophistication, id required. Moreover, if you are using sophisticated tools like Hibernate, they provide the APIs which implement these patterns.

So far in this series, we have discussed the basics of domain driven design. In the next part of this series, I will discuss about Specification pattern.

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.

The DDD Factory pattern is different from the Gof Factory patterns, in that, the Gof patterns are on a technical level, whereas, DDD factory pattern is more on semantic domain model level. In fact, a DDD factory might make use of Gof creational patterns to create the domain objects. From hereon, I will refer DDD factory as a factory and indicate appropriately whenever a Gof factory is referred.

Factories have several benefits over constructors, which are

• Factories can tell about the objects they are creating, while constructors cannot. Let’s take an example, an Order object can be created by passing params or by using an existing object to create a repeat order. So, in the Order class, two constructors for can be created as
  

  class Order{
    public Order(params) {}
    public Order(Order repearOrder) {}
  }
  

  where, if we use factory, we can make code more expressive, as shown below

  class OrderFactory{
    public static Order createOrder(params) {}
    public static Order createRepeatOrder(Order order) {}
  }
  

• Whenever we call a constructor, a new object is created, whereas, we can control object creation by using factory. We can create a pool of objects and we might not have to create new objects every time. This is more applicable in case of Value Objects factories since VOs are mostly immutable we can keep a pool of VOs and avoid new object creation every time.
• Factories are polymorphic, in that, they can return the object or any subtype of the object being created, whereas, constructors do not provide such flexibility.
• In cases where the object being created has a lot of optional parameters, we can have a Builder object as the Factory. Builder is one of Gof’s creational pattern which is used when an object has to be created in steps or when there are large number of optional parameters. For example, If an object has 2 mandatory parameters and 8 optional parameters, then it is not advisable to use constructors as providing constructors for all the combinations would swamp the object with constructors.

In this blog, we discussed about the Factory pattern and it’s advantages over constructors as a means for creating objects. In case of complex objects or aggregates, factories encapsulate object creation logic and make model more expressive. However, in case of simple objects which do not have a lot of optional parameters, it is advisable to avoid factories and stick to constructors.

Factories deal with early life of a domain object, but a domain object has a longer life cycle. A lot of time, we have to resurrect a domain object from storage. This part can be a little different from Factory and that’s why there is a separate pattern for it, which is know as Repository pattern. I will present that in the next part of the series.

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.

Aggregates

In a software system, a common requirement can be to maintain the history of the changes to a user’s payment information, like credit card number, cvv number, etc. Typically, this is done by creating an object for user’s history and persisting it. This can be done as shown in the code below

void updatePaymentInformation(params...) { //service class  method
  User user = User.get(id);

  UserHistory userHistory = new UserHistory(user); //copy constructor to copy auditable fields
  userHistory.save();

  user.setCreditCardNumber();
  user.setCvvNumber();
  user.save();
}

Above code seemingly easy, but logically, UserHistory does not have use without a user. The true identity of the UserHistory is the associated user. So, it is better to manage the UserHistory from the User object itself as shown in the code below.

class User {
  Set<UserHistory> userHistories;
  void updatePaymentInformation(params..) { //user class method
    this.setCreditCardNumber(...);
    this.setCvvNumber(...)
    userHistories.add(new UserHistory(this));
  }
}

In above example, we can see that UserHistory cannot exist without User. So, we can enforce the access to UserHistory through User object only. This will minimize the dependencies between the classes and reduce complexity. The example mentioned in here in trivial, but in real world, there can be many other scenarios where one entity can also exist without another entity, like an Order item cannot exist without an Order, a Book cannot exist without a page. One important thing to note here is that in these examples, the reverse relation is also important, i.e., an Order does not have a meaning without a Order item and nobody will read a book without pages. Here, Book and Order represent a cluster of associated objects, which model something meaningful as a whole but lose importance when separated from each other.

In DDD, such cluster of associated objects is known as a Aggregate. Each aggregate has a root and a conceptual boundary. Root is a specific entity in the aggregate and is the only member of the aggregate visible(allowed to get referred from other objects) to rest of the world. Entities other than the Root entity are local entities, which have identities to distinguish them within the aggregate.

Other than managing the access to local entities of the aggregate, root of the aggregate can also enforce the invariants, which are consistency rules which needs to be maintained whenever data changes. For example, in most Purchase Orders(PO) there is a approval limit. So, whenever a new PO item is added to the PO, we can check whether adding the item will make PO exceed it’s approval limit.

Since aggregates model a concept which represent a meaningful whole, consistency of aggregates are very important. To maintain consistency of aggregates, we need to apply a set of rules, which are

• The root entity should be the only window to the aggregate to the outside world.
• All local entities within the aggregate should be accessed by traversing the tree from the root entity.
• Invariants, if any, should be applied only by the root entity. Invariants should be applied at all times, i.e, whenever a non root member of the aggregate is inserted, update or deleted, all applicable invariants should be satisfied.
• Any object which is outside the aggregate should not have references to entity or value objects which are member of the aggregate. The only exception to this rule is root entity.
• Any update to the non root member should we through root entity as it would help in satisfying the aggregates.

In this blog, we discussed about the Aggregates and the set of rules to be applied while designing them. Although, an aggregate is a cluster of different objects, they represent a business concept as a unit. On the face of it, Aggregates seem to reduce the complexity of the model and make the model clean. But, we should avoid overuse of aggregates. We should avoid overuse of aggregates because

• Overuse would result in deep nested trees and this would require a longer traversal time to the local entities.
• In a distributed environment, serialization and de-serialization would take time if we have deeply nested structures.

Modelling aggregates judiciously would reduce the complexity and maintain consistency of the domain model.

An association is basically a relationship between two entities. There can be a variety of relationships between objects. (Unified Modelling Language)UML specifies a notation for many of them. A succinct list of UML associations can be referred from here. DDD does not add any specific relationship of it’s own but instead suggests to optimize them by

• Imposing a traversal direction
• Adding a qualifier to reduce multiplicity
• Eliminating non-essential associations

An order is placed for a customer, and over a period of time, a customer can have many orders. So, there is a bi-directional one-to-many relationship between a customer and an order. But, a deeper insight might reveal that most of the times we need to know the customer to whom a particular order belongs. But, only in some cases, we need to find out the orders of a customer. So, for simplicity, this relationship can be modelled as a uni-directional one-to-many relationship between a customer and an order and the traversal direction from order to customer. If we need the ability to find orders by customer, this can be done through a database query.

A brokerage account can have many investments. So, there is a one to many relationship between a brokerage account and it’s investments. But most investment are against a stock. So, a one-to-many relationship can be reduced to a one-to-one relationship by adding a qualifier, which in this case would be a stock symbol. This is shown in the following code segment

public class BrokerageAccount {
  Set<Investment> Investments;
  public Set getInvestments() {
    return investments;
  }
}

The above code can be changed to

public class BrokerageAccount {
  Map<String stockSymbol, Investment> investments;
  public Set getInvestment(String stockSymbol) {
    return (Investment) investments.get(stockSymbol);
  }
}

The fact that an investment is against a stock symbol is made more explicit by adding a qualifier which in this case is a stock symbol.

Entities

An entity is something which has an identity and is clearly distinguishable from other entities of same or other type. It can be a person, place, ticket, or anything else which can be distinguished from other entities. The identity of an entity can either be a computer generated number or it can be a combination of the attributes.

Value Objects

Values object are something which represent concepts but does not have an identity of their own. When you care only about the attributes of an object, classify it as value objects. Value objects can

• be an assembly of other objects: For example, in a building plan, a wall consists of window. Both these objects does not have an identity of their own because it may not be required to identify them.
• refer to entities: For example, in an online map service, a route object consists of source and destination city, both of which may be an entity.

Values object makes domain model expressive. For example, the fact that Customer has an Address is made more explicit by modelling Address an a value object.

It is recommended to model VOs as immutable objects. This makes them thread safe and easily shareable. Making a value object immutable also open the doors for some optimization. We can use patterns like Flyweight, which replaces large number of unshared objects with smaller number of shareable objects.

Making a VO immutable seems to be an obvious choice. However, if the value of the VO changes frequently and the creation of a new VO is expensive, then making it mutable seems to be a better choice. Despite all this, always design a VO as immutable and, if required, make it mutable.

Services

In some cases, a particular behaviour does not belong to a particular entity or value object. So, instead of bloating an object with the behaviour it does not intends to do, it is better to model it as a Service. A service provides a behaviour through an interface. The behaviour can be an action, or an activity. A service should not have a state of it’s own so that it can be shared easily and it’s behaviour can be reused easily.

A service can be classified as an application service which is involved with services like transactions, security, logging, etc., and a domain service which encapsulate behaviour not specific to any object. Although, application services provide very important services to an application, but in DDD, domain services are primary concerns while modelling behaviour.

Modules

Modules is a less talked about topic of DDD because the reasons to divide an application into modules are fairly obvious and we have been doing that for a long time. I will reiterate those reasons here once again

• Modules help in breaking down the complexity of an application.
• Modules acts as a communication aid because when we discuss a functionality by associating it with modules, the discussion context is narrowed down.
• Modules facilitate parallel development.

Conclusion

In this blog, we discussed various elements of DDD which makes domain modelling expressive. Constrained associations reduces the complexity of the domain models, whereas  adding directions to relationships makes it more expressive. The idea of having immutable value objects seems to add expression to models by making concepts more expressive. Services take the load off the entities, and since they are interface based, we can change the implementation without affecting the domain object. Modules break the story of domain model into chapters. Applying these concepts judiciously will surely help in expressing a deep insight into the domain of the software.

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.

What is DDD?

A picture is worth a thousand words and, sometimes, is better suited to convey a message. Similarly, a domain model is a simplification of the domain of the software and it abstracts the elements of domain which are relevant to the problem the software intends to solve. A domain model is representation agnostic, i.e., it can be represented as an UML diagram, as written code, as simply plain English, or as a simple diagram. The decision to choose an option depends upon the situation and complexity of the problem. The process of creating, maintaining and enhancing highly expressive domain model by applying objected oriented principles, design patterns is known as Domain Driven Design(DDD). One important point to understand is that DDD is not a one time activity. It is an iterative process and model evolves with the project.

We all know that the process of creating domain model by abstracting from the complexities of a domain is not an easy job. Experienced programmers/thought leaders often compare this job with that of an artist. Few would disagree with them. But, with any art, there are certain principles and practices, which make the process of identifying and representing abstractions simpler. DDD also suggests to employ certain principles and practices, which we may already be doing intuitively, to work with highly expressive domain models. Let’s have a look at some of the principles and practices of DDD.

Getting Started with DDD
There might be several questions, which may be taking shape in the mind right now. Let’s see which DDD principles and practices applies to specific question

Q: I don’t have the domain knowledge. How will I communicate effectively with the domain experts?
A: In most projects, there is an interface between the technical people and the domain experts. We may call this expert a Business Analyst, a Product Owner, or with some other name. Sometimes, this interface is not effective to transform the messages between two parties and in the process of message transformation, some relevant details are missed. This leads to a situation where WHAT takes over WHY.

To overcome this problem, DDD emphasizes to have a close relationship between the domain experts and the developers. Even when a modeler is working with domain experts(DE), he should be hands-on enough to think about design issues while brainstorming with the DE. DDD also suggests DDD developers to pick up key concepts while having conversation with the DE and also educate them about their terminology. This leads to the development of a Ubiquitous Language(UL) which forms the basis of development domain model. UL is basically a medium of communication which is used to develop a domain model. It is also used to validate a domain model periodically. The development of UL is an iterative process and is based on mutual agreement between DE and technical people.

Q: How will I represent my domain model?
A: Domain model should be represented in a way which best communicates the intent of the domain knowledge. It can be in the form of a diagram, a UML diagram, plain English, or simply code. Now, when there is freedom to represent something in multiple forms, how to maintain the sanctity of the domain model. I think that’s the job of the skilled developers or domain modelers. It is difficult to provide a rule for everything and we all know that real world is like that. Sometimes we have to break the rules and take pragmatic decisions. DDD realizes that and promotes developers to take pragmatic decisions instead of being bound by the rules.

Q: How will I layout the architecture of the application with DDD?
A: The focus of DDD is to create domain models that are rich in behavior. Typically, an application has several other issues as well which are not concerned with the domain. To work effectively with DDD, we need to isolate those issues from the domain modelling. In order to do so, we can use layered architecture to isolate and group the problems.

In a layered architecture, each layer is aware of the layers below it. In general, a layer at the lower level cannot make calls to the layer above it.

Q: How will I represent concepts in a domain model?
A: Most concepts in domain can be classified into

• Something which has an identity: Entities. Entities, which are essentially objects, identified by an identity, which does not change. The identity can be a surrogate key or a composite key.
• Something which has an important meaning in larger picture but does not have an identity of it’s own: Value Objects(VOs). VOs represent meaningful concepts and abstracts the details of those concepts but does not have their own entity. For example, a phone number is one such thing, which represent certain information, but does not make any sense if not associated with a person, place, etc.
• Something which relate various concepts with each other: Cardinality. Cardinality represents relationship between various entities. DDD advocates to have minimum cardinality between entities.
• Behavior common to various concepts: Services. Services are components which provides behavior which is not specific any particular entity. These services are different from the application service, in that, they provide services to the domain layer and not callable from the application layer.

Apart from the above, DDD also introduces the concept of Aggregates, which are essentially small group of related objects. Aggregates have a common root and act as an entry point for outer world to the constituents of the aggregate. This helps in managing the complex web of associations in a domain model.

Also, since in many cases, entities will be persisted and again constructed back, DDD advocates the use of Factories and Repositories. Factories are generally used to create complex objects and Repositories are used to reconstruct an already persisted object. Here, Factories is not something which refers to only Factory pattern. We are free to choose from Factory, Builder or any other that we are aware of based on our judgement and something which conforms to UL.

Q: How will I model behavior in domain model?
A: In domain modelling, majorly, we have following kinds of behavior

• One which validates the domain model against certain rules: Specification Pattern. Specification pattern is employed to validate domain model against certain rule. For example, The logic to check whether the project is overdue can be put in the Project object, as in the following listing

class Project {
  public boolean isOverdue() { … }
}

or, it can be abstracted as a Specification, as shown in the following code

public interface ProjectSpecification {
  public boolean isSatisfiedBy(Project p);
}
public class ProjectIsOverdueSpecification implements ProjectSpecification {
  public boolean isSatisfiedBy(Project p) { … }
}
If (projectIsOverdueSpecification.isSatisfiedBy(theCurrentProject) { … }

• One which is algorithmic in nature, like calculations, rules: Strategy/Policy Pattern. Strategy pattern is essentially employed to abstract out algorithms or business rules out of domain model. For example, if there is a business rule to allow Voyage overloading with 10% overloading. Then, without strategy pattern, code might look like
  

   public int makeBooking(Cargo cargo, Voyage voyage) {
     double maxBooking = voyage.capacity() * 1.1;
     if ((voyage.bookedCargoSize() + cargo.size()) > maxBooking)
         return –1;
     int confirmation = orderConfirmationSequence.next();
     voyage.addCargo(cargo, confirmation);
     return confirmation;
  }
          

  After applying Strategy pattern, the code might look like

  public int makeBooking(Cargo cargo, Voyage voyage) {
  if (!overbookingPolicy.isAllowed(cargo, voyage)) return –1;
     int confirmation = orderConfirmationSequence.next();
     voyage.addCargo(cargo, confirmation);
     return confirmation;
  }
  
  public OverBookingPolicy {
  public boolean isAllowed(Cargo cargo, Voyage voyage) {
     return (cargo.size() + voyage.bookedCargoSize()) <=
           (voyage.capacity() * 1.1);
  }
  }
          

  This helps in making code/model more expressive and flexible.

Q: How will I maintain the integrity of the model in a large team with complex domain?
A: While working on large projects and large teams, it is difficult to express the intent of the domain with a single model. DDD advocates the use separate models to model the entire system. The patterns to handle the complexity of working with separate models and communicating between them are grouped as Strategic Design Patterns in DDD. Various strategic design patterns are their relationships are shown in the following diagram.

• Bounded Context: DDD suggests to separate multiple domain models based on contexts. For example, in above figure domain model expressing project model is bound by project context, where as, billing model is bound by billing context. Contexts are generally created based on team structure and domain concepts.
• Context Maps: Different models in an application cannot work in isolation. There will be some data sharing among them. DDD provides some patterns based on experience. Theses pattens have specific applicability which are explained below.
  • Shared Kernel: In this pattern, another domain model is created which models the shared data. For example, in the above example, shared data can be Customer and that would be part of Shared Kernel.
  • Customer/Supplier: This pattern is applied when one context has dependency on another pattern. In this scenario, customers models can discuss their concerns with suppliers and raise their concerns and get the supplier model modified.
  • Conformist: This pattern is similar to above pattern but customer model has no control over supplier model and customers are forced to deal with whatever suppliers dish out.
  • Anti Corruption(AC) Layer: When the supplier model is third party and legacy code, there is high probability that the legacy code is developed not using domain modelling techniques. There might be chance of theses bad practices to creep into your own domain model. To insulate your domain model, DDD advocates the use of an AC layer, which is essentially a collection of services and adapters which translate the communication between the two models.
  • Separate Ways: When the cost of integration between various model becomes overwhelming, we can decide not to integrate them at all. Instead, we can decide to break the application into smaller application which have little or nothing in common from modeling perspective.

Q: How do I learn more about DDD?
A: To get started with DDD, I recommend following approach

1. Download Domain Driven Design Quickly, a brief and concise guide about DDD from InfoQ to get started.
2. Go through, Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans.
3. You can also join Domain driven design group on Yahoo to get connected with the latest in DDD.

Conclusion
In this blog, we discussed about what is DDD and looked at the various pattens suggested by DDD. DDD is not only object orientation done right but also understanding the domain of the application. DDD does not lay down any rules and only suggests to do certain things, which have worked on various projects. Any developer can benefit from it because it is merely a thought process which has evolved based on experience and not is not a figment of anyone’s imagination. DDD, along with Agile practices like TDD, Continuous Integration and Refactoring, is a potent weapon in any designer’s armor.

As promising it may be, DDD’s applicability has major challenges. Based on my experience in IT industry, I have summarized majority of them below:

• Poor quality of requirements: As already discussed in the blog, most projects have a translation layer which translates the requirements between business and technical people. Some may call them Business Analysts, whereas some call them Product Owner. So, quality of communication, and hence the requirements, depend upon this translation layer. On top of that, if this translation layer is bureaucratic, they would not like developers to work directly with the business as it would dilute their role in the project. So, apart from skills, DDD requires people with right mindset at the top and the team.
• Simple Domain: The application/domain may be simple enough to yield any significant ROI of using DDD. The effect of DDD might be visible once the project becomes complex.
• Motivation: DDD is all about making pragmatic decisions and it requires a lot of skill, but more importantly, a lot of motivation to make those decisions.

In summary, DDD is a promising concept, which is gaining momentum in recent years. Although, it may not be applicable to every project directly, but learning these principles would certainly enhance design skills of a developer.

Most enterprise applications use Layering as the primary technique to break the complexity of the software projects. Layering involves breaking down the applications in various layers where each layer lie above the other and provide services to the higher layer. Layering provides following benefits

• You can understand about a layer without knowing about other layers. For example, if you know how TCP works you can create your own FTP service without actually knowing about the internals of the ethernet.
• It is easy to substitute the layers with alternative implementation. For example, if DAO layer is designed properly, if should be easy to change the ORM solution from Hibernate to iBatis easily.
• Layering also helps in standardization and extensibility.

But the downsides of layering applications include cascading changes, performance overhead of converting data from one representation into another and it is not often easy to decide the later of a particular component. Considering the benefits of layering and it’s applicability to almost any sort of computer application, it is used widely and successfully.

Three primary layers of an enterprise application can broadly be categorized into

1. Presentation Layer: Information display, HTTP requests, command line invocations, batch API, etc.
2. Domain Layer: Here lies the “Heart of the software”
3. Datasource Layer: Provides access to external resources like databases, messaging, mail server, etc.

In this blog, we will discuss various patterns of organizing domain logic and specific pros and cons of each. We will also discuss how these approaches compare with each other.

Domain Login Patterns
In his book, PoEEA, Martin Fowler has classified domain logic patterns into three primary patterns: Transaction Script, Domain Model and Table Module. He also discussed introducing an additional layer, Service Layer, which is useful in providing horizontal services. Let’s look at each of these in detail.

Transaction Script (TS)
Transaction script is essentially a procedure that takes input from the presentation, processes it with validations and calculations, stores data in the database, send emails, etc. It may also fetch the data and send to the UI. It’s more like coding a C program in Java. Typically, in transaction script method of organizing domain logic, the code is segregated into various services and each service has methods that perform a particular business functionality. A method of a transaction service might look like this

void tsmethod(params) {
   // get data
   // process data
   if () {
   } else if {
   } else {
   }
   // insert/update/delete data
   //send email
}

As you can see from the above, most of the of the above code is procedural. Here, the services act on the entities. A typical example would be an interaction between session bean and entity bean. Another similar pattern not mentioned in the PoEEA is Anemic Domain Model (ADM) which works on the same principle where domain objects have attributes and relationships but does not have behaviour. Behaviour is provided by the services. The different between TS and ADM is that in former we do not have domain objects but rather have something which Fowler describe as Table Data Gateway, which essentially is a wrapper for SQL queries.

Domain Model (DM)
In domain model approach, both behaviour and data are encapsulated inside the domain objects. Domain model looks different from the database design and utilizes inheritance, strategies, and other design patterns to create complex webs of small interconnected objects. A typical domain model code might look like

class Bar {
  private BarAdmissionPolicy = new BarAdmissionPolicy();
  public void admit(Person person) {
     if (BarAdmissionPolicy.isAllowed(person)) {
         this.add(person)
     }
  }
}
public class BarAdmissionPolicy {
   public boolean isAllowed(Person person) {
     if (person.age > 18) {
        return true;
     }
     return false;
   }
}

A well designed domain model provides an abstraction of the domain logic. It encapsulates complex business logic as interactions between domain objects.

Table Module (TM)
It is essentially a singleton instance that handles the business logic for all the rows in a database table. There is no concept of identity in a Table Module. It is designed to operate on entire table data. A typical domain might look like

class Product {
 void insert(name, type, etc) {
 }
 void insertAll(List) {
 }
 void calculateProductCost(List productIds) {
 }
}

As you can see, a table module encapsulates the data and behaviour of the entire table. It is most commonly used in places where UI widgets are data-aware like Oracle Forms or .Net environment which has Visual Studio, which provides tools like RecordSet.

Service Layer (SL)
A Service Layer defines an application’s boundary and its set of available operations from the perspective of interfacing client layers. It encapsulates the application’s business logic, controlling transactions, applying security and coordinating responses in the implementation of its operations. Service Layer can be thick or thin depending upon whether you are using transaction scripts or domain model.

Now, we have understanding of the various domain logic patterns, let’s discuss how they compare with each other.

Comparison
Essentially, if you are using one of DM, TM or ADM pattern, the domain layer can be split into two layers: SL + DM/TM/ADM. SL is essential in providing horizontal services like security, transactions, etc. With TS in practice, it is difficult to identify the difference between SL and TS since TS can double up as a SL also.

Since, TM emphasizes one class per table, there are issues in implementing OO concepts while inheritance. There are no direct relationships between objects. For example, if you want to get a List of Products and Categories separately then it is easy to define where to put the code, but it is not clear where to put the code if you need a RecordSet which contains both Products and Categories.

TS is more like a service class which makes implementing domain logic difficult when the complexity of the application increases, but works well for simple applications.

There is a tough competition between ADM and DM. DM is essentially a Rich Domain Model (RDM). Common things between them includes data and relationships. But things specific to RDM is behaviour of the domain model. There has been a heated debate between designers to prove the dominance of one over the other. Suprisingly, the wiki page for ADM lists why should be avoid them. I reiterate them here

• Logic cannot be implemented in a truly object-oriented way unless wrappers are used, which hide the anemic data structure.
• Violation of the principals information hiding and encapsulation.
• Necessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model’s objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
• Necessitates a global access to internals of shared business entities increasing coupling and fragility.
• Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.
• Necessitates a service layer when sharing domain logic across differing consumers of an object model.
• Makes a model less expressive and harder to understand.

The difference between ADM and RDM is the focus of control. In the former, the services has the control and in the later domain objects controls the services. It is shown in the following diagram.

Another benefit that differentiates ADM and RDM is that in ADM a developer has to understand two layers, service layer and domain layer but in RDM once you get the grasp of domain model, which is essentially a model of the domain logic, you get a grasp of the business and can work productively to enhance the software. RDM also makes code cohesive.

Experts also advocate to consider maintainability while deciding to choose between various approaches. In his book PoEEA, Fowler explains this with the help of a diagram which is shown below

The source of the above diagram is not known. But, according to this diagram, it takes time to pick up speed with the domain model. Of course, with skilled developers the initial startup time reduces. But, as the complexity of the application increases, it becomes increasingly difficult to maintain the application if it is coded with TS pattern. TM pattern delays the cutoff point where DM takes over, but TM is advocated for .Net environments as Visual Studio provides tools which work well with TM.

Conclusion
In this blog, we discussed various patterns for organizing domain logic in enterprise applications. Clearly, there is no silver bullet which fits all scenarios. Since, we work with object-oriented programming languages, it is advisable to work with approaches like DM to encapsulate business logic. Also, it makes working with complex applications easier as the complexity of the application increases. DM helps in abstracting a model of the real world domain logic in the code which once understood can make working on the applications more productive and fruitful. For simple applications, TS/ADM meets the requirements.

But, how to decide whether the application is complex or easy. Most of the metrics talk about the complexity once the software has been coded by analyzing if-else statements, cyclomatic complexity, etc. But, here, we are talking about predicting complexity, and there is no known metric which can objectively tell that. However, it can be subjectively predicted by knowledge of the domain of the software, which is gained by experience.

Another and most important factor which must be taken into consideration is maintainability. Although it cannot be quantitatively measured, but since we work in to the objective oriented world, DM seems to have an edge over other approaches and it employs inheritance, polymorphism, etc to encapsulate the domain logic.

As a final word, all the above domain model patterns are not mutually exclusive and an understanding of all of above might help us decide an approach for developing a particular software.

To devise a solution, I thought that most users would not register account on the same website again at least with in a day, may be a year also. So, using this fact, the proposed solution was to display the captcha only when the user is registering again on the website. In this way, we could avoid irritating the user by showing the captcha, but if needed, we can again activate captcha for second or subsequent captcha.

The proposed solution brought an interesting challenge. How would we determine whether the request is coming from the same machine? HttpServletRequest.getRemoteAddr() gives you the client local IP. But, if you are behind NAT, you might not get different IPs for different machine.

In order to resolve the above mentioned issue, we can use X-FORWARDED-FOR, which is a HTTP header that is inserted by proxies to identify the IP address of the client. It can also be added to requests if application servers are proxied by proxy servers. In this case, the request IP address is always a local address and the client IP address must be extracted from the request. Since proxies can be chained – for example if the client’s request is already made through a proxy – the X-FORWARDED-FOR header can contain more than one IP address, separated by commas. In this case, the first one should be used.

The solution is still not full proof, because headers can be tampered easily. To rescue comes a module of Apache http server, which is mod_remoteip,
Thanks to this, request.getRemoteAddr(), request.getRemoteHost(), request.isSecure(), request.getScheme() and request.getServerPort() will expose the values transmitted by X-Forwarded-For and X-Forwarded-Proto rather than the values of the preceding proxy / load balancer.

The above mentioned Apache module works on an open source project, RemoteIpValve, and, XForwardedFilter. The RemoteIpValve and the XForwardedFilter have been integrated in the Tomcat Project. The RemoteIpValve will be available in the forthcoming Tomcat 6.0.21 version, whereas, XForwardedFilter has been renamed RemoteIpFilter and will be integrated in Tomcat 7.

Thanks to all those who worked on RemoteIpValve and RemoteIpFilter.

Prior to JSR 286, the support for inter portlet communication was rather minimal and information sharing between different portlets was accompalished primarily using application scoped session objects or vendor specific APIs. Both of above methods were rather problematic as in the former maintaining the uniqueness of the session attribute over a complex aaplication was a concern and in the later portability of the portlet was hampered. In order to provide coordination between portlets the Java Portlet Specification v2.0 (JSR 286) introduces the following mechanisms:

1. public render parameters in order to share render state between portlets.
2. portlet events that a portlet can receive and send.

Let’s have a look how to use the above features.

Public Render Parameters

In JSR 168, the render parameters propagated by one portlet were only available in the render method of the same portlet. This is explained in the following figure.

In JSR 286, the render parameters propagated by one portlet can be made available to the render methods of other portlets. This is explained in the following figure.

In order to allow coordination of render parameters with other portlets, within the same portlet application or across portlet applications, in JSR 286 portlets, the portlet can declare public render parameters in its deployment descriptor using the public-render-parameter element in the portlet application section. In the portlet section each portlet can specify the public render parameters it would like to share via the supported-public-render-parameter element. The supported public-ender-parameter element must reference the identifier of a public render parameter defined in the portlet application section in a public-render-parameter element. The portlet should use the defined public render parameter identifier in its code in order to access the public render parameter.

Let’s see how it works..
Consider the following example..

1. Set the public render parameters at the portlet application level.

   
<public-render-parameter>
    <identifier>id1</identifier>
    <qname xmlns:x="http://sun.com/params">x:param1</qname>
</public-render-parameter>
<public-render-parameter>
    <identifier>id2</identifier>
    <qname xmlns:x="http://sun.com/params">x:param2</qname>
 </public-render-parameter>

<portlet>
<portlet-name>PortletA</portlet-name>
  <supported-public-render-parameter>id1</supported-public-render-parameter>
  <supported-public-render-parameter>id2</supported-public-render-parameter>
<portlet>
<portlet>
<portlet-name>PortletB</portlet-name>
  <supported-public-render-parameter>id1</supported-public-render-parameter>
</portlet>
<portlet>
<portlet-name>PortletC</portlet-name>
  <supported-public-render-parameter>id2</supported-public-render-parameter>
<portlet>

Portlet Events
Portlet events could be generated as a result of a user interaction with other portlets. The portlet event model is a loosely coupled, brokered model that allows creating portlets as stand-alone portlets that can be wired together with other portlets at runtime. Portlet programmers should therefore not make any specific assumptions about the environment of portlets they are running together with. The means of wiring different portlets together is portal implementation specific. An example where a portlet may want to offer receiving events is for state changes triggered by simple user interactions, e.g. adding an item to a shopping cart. By offering this as an event to other portlets these can trigger adding items to the shopping cart based on the user interactions happing inside these portlets.

EventPortlet Interface
In order to receive events the portlet must implement the EventPortlet interface in he javax.portlet package. The portlet container will call the processEvent method for each event targeted to the portlet with an EventRequest and EventResponse object.

Events are targeted by the portal / portlet container to a specific portlet window in the current client request. Events are a lifecycle operation that occurs before the rendering phase. The portlet may issue events via the setEvent method during the action processing which will be processed by the portlet container after the action processing has finished. As a result of issuing an event the portlet may optionally receive events from other portlets or container events. A portlet that is not target of a user action may optionally receive container events, e.g. a portlet mode changed event, or events from other portlets, e.g. an item was added to the shopping cart event.

The JSR 286 event processing is explained in the following figure.

To create portlets that use the eventing feature, follow these steps
1. Declare the events in the portlet.xml
(i) Set the event definition at the portlet application level. This specifies the event name and the object type.

<portlet-app ...>
<portlet>
 . . .
 . . .
 </portlet>
 
 <event-definition>
   <qname xmlns:x="http:xebia.com/address">x:Address</qname>
   <value-type>com.xebia.Address</value-type>
 </event-definition>
</portlet-app>

  @XmlRootElement
  public class Address implements Serializable {
      public Address() {
      }
      private String street;
      private String city;
      private String country;

      //getters and setters
   }

(ii) In the portlet section, specify the event name defined above for those portlets that want to publish this event.

<portlet>
  <description>ContinentPortlet</description>
<portlet-name>ContinentPortlet</portlet-name>
    .................
   <supported-publishing-event>
     <qname xmlns:x="http:xebia.com/address">x:Address</qname>
   </supported-publishing-event>
</portlet>

<portlet>
  <description>ContinentMapPortlet</description>
<portlet-name>ContinentMapPortlet</portlet-name>
  <supported-processing-event>
    <qname xmlns:x="http:xebia.com/address">x:Address</qname>
  </supported-processing-event>
</portlet>
<portlet>
  <description>ContinentInfoPortlet</description>
<portlet-name>ContinentInfoPortlet</portlet-name>
  <supported-processing-event>
    <qname xmlns:x="http:sun.com/events">x:Address</qname>
  </supported-processing-event>
</portlet>

public class ContinentPortlet extends GenericPortlet {
   public void processAction(ActionRequest request, ActionResponse response)
   throws PortletException,IOException {
	QName qname = new QName("http:xebia.com/address" , "Address");
        Address add = new Address();
        //set values in address
        response.setEvent(qname, add);
    }
}

public class ContinentInfoPortlet extends GenericPortlet {
  public void processEvent(EventRequest request, EventResponse response) {
    Event event = request.getEvent();
    if(event.getName().equals("Address")){
      Address payload = (Address )event.getValue();
      //process payload here
    }
  }
}

However, as per the portlet specification, portlet events are not as reliable means of communication as is JMS, since the specification does not mandate the portal containers to persist the portlet event data. So, in case of server failures, the portlet events can be lost.

Summary
In this blog, we discussed about the JSR 286 inter portlet communication features. First, we discussed about the public render parameters and how it works. Secondly, we discussed about the portlet events, and it’s working. So, how to decide when to choose either of the above two portlets. I would use the following principle

In case, the receiver portlet, does not need to do any processing/businees logic, it is advisable to use public render parameters as they avoid the overhead for portlets event creation and wiring the portlets together, which is required in case of portlet events. As already discussed, wiring portlets together is portal container specific and is an addtional overhead. However, to allow receiver portlets to process the shared information and sending type safe values, we need to use portlet events.

Overall, JSR 286 portlet coordination features make complex portal applications modular and manageable.

Note: The source code for the portlet event can be downloaded from here.