1

In an ASP.NET MVC world, could controllers act as the application layer, calling into my domain objects and services to get the work done (assuming the controllers just strictly calls the domain and does nothing more). In the particular case that am dealing there is very minimal application flow logic that I need to model, hence am thinking about doing away with application layer and calling the domain directly from within the controller.

Is this a fair approach?

kayess
  • 3,384
  • 9
  • 28
  • 45
Karthik Balasubramanian
  • 1,127
  • 4
  • 13
  • 36
  • 1
    As long as you understand the implications of your design there are no definitive rules on what you can and cannot do. It always comes down to costs-benefits trade-offs. In this case, simplicity at the expense of a loss of flexibility. E.g. what if you have multiple UIs down the road? What if external systems must interact with your application? I usually prefer to add the additionnal layer of indirection right away because it isin't that coslty and may save you a lot of refactor down the road. – plalx Jan 04 '17 at 15:22
  • 1
    People get too focused on these design patterns. They're patterns because the problems they solve are common enough that many people end up doing the same type of thing over and over. However, not every application needs every pattern. Design your application according to the needs of your application and stop worrying about whether or not you're checking all the boxes on the design pattern checklist. – Chris Pratt Jan 04 '17 at 15:39
  • @plalx: Adding an additional layer of indirection right now seems like a overkill to me at this moment, I completely understand your case though. Am willing to keep it simple knowing that the cost of introducing another layer comes with a cost. – Karthik Balasubramanian Jan 04 '17 at 15:55
  • @Chris I had to ask this question just to make sure that I have not grossly overlooked anything. – Karthik Balasubramanian Jan 04 '17 at 15:55
  • 2
    I wasn't being antagonistic about it. Just meant that only you can say what is or is not a good idea for your application. Design it in the way that makes the most sense, and everything else will sort itself out. Following these patterns are meant to reduce the cost of maintenance. However, implementing them has its own overhead. It's always a balancing act of building for a potential future that may never happen or just doing what's required now. Ultimately it's always a judgement call. – Chris Pratt Jan 04 '17 at 18:36

3 Answers3

1

I guess what you mean here is that your business logic is implemented using the Domain Model pattern. In such case, you application layer should be very simple, and by definition it shouldn't host any business logic. All business logic should reside in the domain layer; methods in your application layer should resemble the following steps:

  1. Load instance of an aggregate
  2. Execute action
  3. Persist the updated aggregate
  4. Return response to the user

If that's all you do in your application layer, I see no reason not to put it in the controller.

If, on the other hand, your domain model is anemic, and you do have business logic in the application layer, then I'd prefer to introduce a separate layer.

Vladik
  • 176
  • 1
  • 7
0

Treating your MVC controllers as your DDD application layer will present a few negative situations.

The biggest one is that your application layer (regarding DDD), is one of the key places where you model your domain/business processes. For example, you might in an application service have a method called:

PayrollService.CalculatePayslips();

This might involve, checking a domain service or external system for the current active employees, it might then need to query another domain service or external system for absences, pension deductions, etc. It will then need to call a domain service (or entity) to do the calculations.

Capturing domain/business logic like this in the MVC controllers would cause an architectural issue, should you want to trigger the task of calculating payslips from elsewhere in the system. Also if you ever wanted to expose this process as a web service, or even from another MVC controller, you would have references going across or up into your presentation layer. Solutions like these "might work", but they will contribute towards your application becoming Spaghetti Code or a Big Ball of Mud (both code smells in an architectural sense). You risk causing circular references and highly coupled code, which increases maintenance costs (both time, money, developer sanity, etc.) in the future.

At the end of the day, software development is a game of trade-offs. Architectural concerns become bigger issues, the bigger your application grows. For a lot of very small CRUD apps, architectural concerns are probably negligible. One of the key goals of DDD is to tackle complexity, so it could be argued that most DDD projects should be of sufficient complexity to be concerned about good enterprise architecture principles.

Adrian Thompson Phillips
  • 6,893
  • 6
  • 38
  • 69
  • I hear your concern, but am a big fan of YAGNI, currently as I know it, my controller needs no application logic. It seems to me creating an application layer just because I might need it in the feature seems or because that is the right thing to do just doesn't sit well with me. But I do appreciate your points, it did reiterate to me the need for application services (where we need them) – Karthik Balasubramanian Jan 05 '17 at 12:56
  • 1
    Fair enough, architecture decisions depend on many things, it's always a balancing act. If it's your own application (just you developing it), it's small in size, it's not likely to grow (or it has a short lifespan) and no other developers have to maintain it, then there is probably no benefit in making things more complex than they need to be. – Adrian Thompson Phillips Jan 05 '17 at 15:03
  • There's also unit testing to consider. It's generally harder to unit test a controller than a suite of class library methods. Again, if you're just experimenting, writing a small application, etc. you might find no benefit in unit testing your code. – Adrian Thompson Phillips Jan 05 '17 at 15:06
0

I would not do it.

The effort of creating a separate class for the application service and then invoke it from the controller is minimal. The cost is also only there when you build the application.

However, the price you have to pay once you start to maintain the application is much higher due to the high coupling between the business layer and the presentation layer.

Testing, reuse, refactoring etc is so much lower when you make sure to separate different concerns in an application.

jgauffin
  • 99,844
  • 45
  • 235
  • 372