Posted on
September 4th, 2011
In my current project, I was exploring options to use a framework to develop portlets in Liferay portal. Finally, we decided to use Sprint Portlet MVC. We were successful in developing data driven portlets using Spring Portlet MVC and Hibernate. However, we were told to use Liferay ServiceBuilder to develop services instead of Spring and Hibernate. In the end, the tech stack to develop portlets was Spring Portlet MVC to develop the portlets and Liferay ServiceBuilder to develop services. This post mentions the problem we faced in integrating Spring Portlet MVC with Liferay ServiceBuilder. Read more »
Posted on
May 12th, 2011
I had just started exploring Ruby and Rails and I came across a nice tool, RVM (Ruby Version Manager), which allows you to install and manage multiple versions of Ruby on the same machine. Although RVM works on Linux based systems only, but windows users can accomplish the same feat with Pik. RVM not only helps in managing different versions of Ruby on the same machine, but it also facilitates working with different combinations of Ruby and Rails. In this blog, I will share my experience of installing RVM and using it to manage different Ruby and Rails versions.
Read more »
Posted on
January 27th, 2010
In the previous post, I discussed about how to query the domain objects. That post completes the issues with domain object lifecycle management. In this post, I will discuss how to make implicit concepts explicit in order to make domain model more expressive by using Specification Pattern.
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. Read more »
Posted on
December 30th, 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 more »
Posted on
December 23rd, 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 more »
