DDD - Factories and Repositories

There is this chapter about factories and repositories. The first to create new entities or aggregates. The second to retrieve/store the entities from/to a database.

There is this mysterious middle ground where you don't have too many associations. Where you normalize but not too much. You create a complex query engine but impose some restrictions to what should be retrieved. I agree, and have been there before, where too many associations tend to cause a graph loading issue. It may appear as too many resources to load an entity by a filter, or even worse, as a lazy initialization - no session in NHibernate. It is very difficult to achieve this middle ground. There is a compromise involved in richness of the model and speed/memory/session handling. On the other hand, to avoid the use of the associations is a way to kill the domain model completely. Removing its meaning and making it just a set of disconnected types.

I developed this filter type of criteria that uses allows the client to use the model to retrieve objects using a very declarative syntax. With this approach, by encapsulating the ORM framework and abstracting its complexities, I can say we have 90% or more of all needs satisfied. And it seems like the way to go. But the use of traversal to navigate the domain model, implying in an underlying implicit querying mechanism to retrieve the objects, although powerful, brings us too much complexity in terms of the lazy initialization nightmare. We end up loosing too much time trying to figure out how to fix these infrastructure issues then working on the model. When the issue arises, I have to say.

I have a feeling that most of the problems we end up having could be solved by a more DDD approach in terms of the usage of aggregates to encapsulate a group of dependent related entities and maintain its invariants. That would simplify a lot the way we interact with the objects in all business logic code and at the same time it would help us to build more reliable user interfaces.

Domain-Driven Design - Aggregates

As I go reading this excellent book, the more and more I have to recognize the greatness of this book in terms of its contents.

This chapter is very clear discussing a very hot topic which is how to encapsulate the invariants of a system.

I never really used this aggregate concept in my projects but the need for the very same solution became very clear in a recent project I am working on. There is always a heated debate in terms of if the invariants should be by entity, enforced on the database or even using the document model which is very close to aggregate as I understand, they might even be synonyms depending on who is talking about them.

The only point I am waiting for a better answer in the next chapters is related to the access of internal aggregate elements: According to Evans, they should be only accessible through the root aggregate entity, but I know many models where one entity from a clear aggregate points to another one on another aggregate. Lets say, details that have links to each other. I tend to think that those type of models might be wrong, and they probably are, but eventually as in the car parts example, one might want to tun a query to get all the cars where the tires needed to be rotated in order to send letters to the customer as a friendly reminder. I will keep on reading and see, I think.

Domain-Driven Design - Modules

I tend to agree with Eric Evans when he talks about Modules in his book. As before, reading his examples and considerations looks like someone who had seen most of what I have experienced as a programmer.

The technological layer architecture has been used in many of the projects I worked on and is one I always try to push onto the design of my applications, even recent ones. But after the initial benefit we get from the separation of concerns like database access, presentation, services as stateless classes, we end up with a set of layers that really don't like to be extended. Not that they are closed to extension, but the whole concept of the entity is scattered through at least 3 layers and if we use any work flow framework on top of it, we will end up having 5 layers to deal with.

I am eager to finish up this book and start trying out some of the concepts in small scoped projects just to see where it will lead the code in the end.

Anyway, modules should be used as a way to simplify the understand of any big domain-model by restricting a set of concepts based on a commonality between them. By using modules effectively we create this subset of functionality that should be easier to grasp than the whole myriad of disconnected information that is usually mangled together in a uncoordinated way in most of the projects I worked in the past.

Studying Domain-Driven Design

I started reading the Domain-Driven Design book, by Eric Evans some weeks ago and today I restarted reading the chapter on Entities, Value Objects and Services.

From the first chapter of the book I had the feeling the author really knows what he is talking about. I always had the feeling that Object Oriented design was a problem when applied to a real world application, especially when we ended up having to decide for more then 30 minutes where a method should be implemented from the actual domain model entities. The service concept is perfect to solve this type of problem nicely by the use of those stateless process coordinators. They have the sole purpose of coordinating the execution of an activity that deals with a group of entities.

I used to simplify my projects by avoiding the implementation of almost any behavior on an entity, but I am reconsidering my position after reading this excellent book. I didn't finish yet.

I hope it will give me some light onto this holy grail of software engineering which is to build great software.

By the way, great software for me is a software that does what it is supposed to do, that is easy to maintain and easy to extend.

What tools I use to LISP

I started to study LISP a while ago and after all this months I am no more than a real beginner, however every time I use LISP I enjoy every piece of code written.

If you want to be easily up and running using LISP and are used to an IDE like I was. I recommend using CUSP with Eclipse. It is very good in terms of productivity and easy to install. Check out this link that teaches step by step how to install it on your system.

How to Install and use CUSP on Eclipse

By the way I use Ubuntu Linux 7.04 hopefully upgrading by the end of the month to the new 7.10.

The LISP implementation I use is SBCL. Make sure you have a link to its manual

I started studying the book Practical Lisp, but couldn't finish the book. The examples at the end weren't appealing to me so I switched to On Lisp which is too deep to me as a beginner and finally to Successful Lisp. In my opinion they are all good books, Successful Lisp and Practical Lisp being the best beginner's books. I hope I will be able to get back to On Lisp when I get more experienced.