The Pendulum of Architecture

If you’re a developer, you’d probably have to have spent the last couple of years in a coma to not notice a trend towards simpler tools, but I want to write a bit about the changing tides in software architecture because I think there is more below the surface.

Around 3-5 years ago was the peak of an era that could be called “the Church of Martin Fowler”. Big software design patterns were in. All of our domains were to be modeled, everything needed a service class, and interface oriented design was all the rage.

Before anyone gets upset that I’m disparaging Martin’s name, let me see the man is a genius. And like any object of worship, terrible things have been done in his name, whether or not he asked for them. In other words, many of these patterns were applied to pieces of software that did not fit the patterns.

But I’m less interested in debating the past and more interesting in discussing where we are now. Rails was one of the first blows against large, complicated software creation. Today, many in the ruby community talk about the bloat of rails, preferring frameworks like padrino, sinatra, etc. Most new languages build super light weight web frameworks first. Look at compojure for clojure, or express for node. Personally, I happen to really like Sinatra, and have used it for a handful of sites that I help with in my personal time.

Does this mean software patterns are dead? Should we all move back to php (which may have been ahead of it’s time)?

I think there is something else going on, namely that tools are addressing a different level of the problem. Pragmatic programmers (literally, not referring to the publisher) often site the adage “use the tool for the job”. Combined with the long cited un*x philosophy that its tools “do one thing well” we can see a pattern emerging. Sites can do one thing well, expose their interactions via http, and build a system of of smaller systems and their interactions.

I don’t think the tools are moving away from complexity for simplicity’s sake, I think they are moving to a new way of dealing with complexity. The tools (sinatra, express, nancy) are designed to create subsystems and you are expected to stitch the subsystems into the complex systems.

It’s like SOA, with http as the service bus, and more explicit dependency bindings.

I think that’s an important distinction. Enterprise architects look at some of these simpler tools and feel that they are toys for smaller sites. But those that embrace them are saying back to that architect “why have tools that provide safety and assimilation across 50 developer product teams, when you can avoid having one big project with 50 developers?” And that’s not a bad question. There are some real analogies to Steve Yegge’s recent software conservatism vs liberalism post.

I’m not taking the position that one side is always right. These are approaches, and any approach tends to have contexts that are it’s sweet spot. But I think this new trend is massively misunderstood. Similar to how many folks think that NOSQL means “No SQL”, instead of “not only sql”.

One question is, can the vendors catch up? Or will this only be an open source trend? Microsoft cleaned up it’s web stack with ASP.Net MVC, but it’s still on the heavy side in comparison to the direction that the open source community is heading. Does Microsoft have the capability to embrace something the size of Nancy? Some would argue web pages (razor) was that answer, but it seems to lack the first class prioritization of routing and http that the open source frameworks do.

Thinking back, it’s easy to wonder why this didn’t happen sooner because of SOA. Maybe this is what the SOA community missed, that better (and simpler) tools were needed to build at the new level that SOA asked the developer to target.

Datalayer Decisions (Repository, DAO, Services) in Domain-Driven-Design Applications

I have been working several applications lately at work that use Domain-Driven Design.

I had a couple of questions about design choices I saw made in the applications I’m working with. I recently talked to an architect who uses DDD a lot (Model first), and had the chance to pick his brain. Here’s what I came up with. I’d be curious to hear other opinions via comments:

1. Why choose Repository vs DAO pattern or vice-versa? I even found some Spring posts recommending both.

Answer: Repository fits nicely on a legacy schema. If you’re domain objects do not match the database, then there this pattern works better. For green field, DAO choice means you can simplify mapping, because your schema is under your control.

One additional consideration: DAO model first means that your database may not be normalized and / or friendly for reporting tools etc. If you are in an enterprise setting, that reporting should be done off of a separate schema anyway (data warehouse). The warehouse records can be written in the service layer (see question 2) or extracted via an ETL process batch job. If this is overkill, then you may want to use Repository and map to a friendlier schema.

In the case of using both repository and DAO, this seems to be of value when you are not using an ORM. The DAO simply manages CRUD for one table, and the Repitory layer handles joining and translating entities into domain objects.

2. What is the purpose of a service layer that encapsulates a DAO or Repository?

Answer: There are various concerns that relate to the application, but not the domain model. For example, a Product model will have validation that is true in and of itself. For example, it must have a name, and that name is 50 characters or less. But in the context of an order, there may be additional validation rules that involve various domain models in the context.

So the service layer should provide a single interface for various actions related to domain that the User Interface layer should call. So for instance, a web application has an admin section where I want to delete a product. And a product can only be deleted without orders.

Top to bottom, the stack looks like the following:

  • Web application: Sends request to Product Service to delete a product
  • Product Service:
    • Calls OrderRepository to validate there are no related orders
    • Calls ProductRepository to delete Product

That is rather simple logic in the service, but why should the product repository know about the order repository? These services serve as single endpoints for user interface programmers. They can simply request a product deletion and handle appropriate validation messages / errors. They don’t care about context validation, model validation, and all the sub steps involved, that is handled for them.

And each class follows the single responsibility rule.