08 September 2010

How much granularity is enough?

I worked sometime ago on a small/medium sized ERP project. Once again it was a ASP.NET web application.
In order to write a feature the following steps must had to be taken:

  1. Write a stored procedure, or two

  2. For each procedure write a method in the related data service in the data access layer of the application

  3. For each method in the underlying data access service write one or more methods in one or more repository objects in the logic layer.

  4. Write one or more entities, value objects and aggregates related to the procedure written.

  5. For each function write a method in the appropriate object service on top of the logic layer.

  6. On the front end write a service facade for collecting errors and results from the logic service, once again is a one to one mapping (I used the ObjectDataSource control extensively in this project and we had a centralized message collecting system).

  7. Write the functionality on the screen.


When looked from a theoretical aspect each step made sense. A clear separation of concerns, each object doing its small thing etc. But during the implementation I just often found my self wondering Why am I doing this? Each object has only a small variation from the object bellow. Isn't this to much granular?.
It sure made writing tests easier, since the logic in each object wasn't very complicated so the corresponding tests were easier to write and were written much faster, especially on upper layers where I made extensive use of the Moq mocking framework.

2 comments:

  1. IMHO, DDD concepts in small projects are anti-patterns. There's no added value, just added complexity.

    ReplyDelete
  2. I have two reasons for you:
    1. Every project grows and DDD helps handling that complexitiy.
    2. It is easier to learn the DDD development style and patters on a small project then on a large project.

    ReplyDelete