Does More Layering will do the Job?

Question

Consider there is a very complex business requirement, that need several business logic steps to be executed when an operation is initiated. For example, when user submit a request then the steps needed to be executed is:

• Validate the data
  • Validate if request already exists
  • Validate if user is exists
  • Validate if user has sufficient financial amount to submit the request
  • Validate if user can immediaetly publish the request
  • Validate if there is item for the request
  • Validate if the item for the request is valid
  • Validate the item to have no negative amount
  • ... (further validation)
• Store the data to repository
• Send e-mail to user or appropriate party
• ... (maybe another steps to be done)

The example above may be far from a real business requirement, but considering it is, then what I imagine is that there will around 10+ services for this operation.

When using constructor dependency, it should be a bad thing to have 10+ constructors, so I think refactoring it will do the job. Some illustration of the refactored design:

ISubmitter(IValidator, IRequestRepository, INotification)
IValidator(IRequestValidator, IItemValidator)
IRequestValidator(IRequestRepository, IUserValidator, IItemExistValidator)
IUserValidator(IUserRepository, IUserFinancialValidator, IUserPublisherValidator)
IItemValidator(IItemRepository, IItemAmountValidator)
... // maybe more

The item amount validation process has made 4 layers from the submitter: ISubmitter->IValidator->IItemValidator->ItemAmountValidator.

I know that in terms of Separation of Concern, I can easily get the correct implementation in which I need (example: ItemAmountValidation). But in terms of debugging code, won't it make harder to track which validation class it use? Since the constructor injection is defined in implementation and not in the interface?

Consider the worst scenario, when the debugger is not the developer, there is only a minimum test scenario and there is no documentation at all.

Answer 1

The logic you are talking about belongs to different layers, but need to be injected into your application layer. What I would do is inject the components needed to do the tasks, like a command handler that executes the request; a validator that takes care of validating input, a repository that will handle data logic, and a Mailer component (or service) that will send the mail.

It's all about putting the responsibilities in the correct component. Constructor injection is an excellent choice that give you a lot of advantages concerning flexibility, testability and it makes your code understandable.

As far as debugging goes, I don't think the little more effort you have to do should be a reason to not structure your code in a modular way. Just set the correct breakpoints and it's fine.

Maybe http://tinyurl.com/d99w8rl can give you some more insight.

Answer 2

But in terms of debugging code, won't it make harder to track which validation class it use? Since the constructor injection is defined in implementation and not in the interface?

Yes, it probably would make you have to jump through more classes when debugging. However, this kind of design allows your code to be tested (using TDD of course) and when practicing TDD, you will have to debug your code much less then before.