Over a million developers have joined DZone.

What's the big deal about limiting abstractions?

DZone's Guide to

What's the big deal about limiting abstractions?

· ·
Free Resource

When I started out, I pointed out that I truly dislike this type of architecture:


And I said that I much rather an architecture that has a far more limited set of abstractions, and I gave this example:

  1. Controllers
  3. Entities
  4. Commands
  5. Tasks
  6. Events
  7. Queries

That is all nice in theory, but let us talk in practice, shall we? How do we actually write code that actually uses this model?

Let us show some code that uses this type of code, this type, this is from the C# port of the same codebase, available here.

public class CargoAdminController : BaseController
  public ActionResult Register(
      [ModelBinder(typeof (RegistrationCommandBinder))] RegistrationCommand registrationCommand)
      DateTime arrivalDeadlineDateTime = DateTime.ParseExact(registrationCommand.ArrivalDeadline, RegisterDateFormat,

      string trackingId = BookingServiceFacade.BookNewCargo(
          registrationCommand.OriginUnlocode, registrationCommand.DestinationUnlocode, arrivalDeadlineDateTime

      return RedirectToAction(ShowActionName, new RouteValueDictionary(new {trackingId}));

Does this looks good to you? Here is what is actually going on here.


You can click on this link look at what is going in here (and I removed some stuff for clarity’s sake.

This stuff is complex, more to the point, it doesn’t read naturally, it is hard to make a change without modifying a lot of code. This is scary.

We have a lot of abstractions here, services and repositories and facades and what not. (Mind, each of those thing is an independent abstraction, not a common one.)

In my next post, I’ll show how to refactor this to a much saner model.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}