Software Architecture Patterns
Anuradha Wickramarachchi

I always like seeing articles on Design and wish more developers used a layered approach. I prefer an extra layer that I call the Application Context layer. There I create Mediators, Facades or models. Basically it is a layer that your views or web services use to get or act on your business. The mediators act like a headless application. Meaning it doesn’t care if it is a web service, windows application, NT service etc. It just does its very focused job. Meaning there isn’t one mediator for your entire application, there could be hundreds. I agree with closed layers, The Layers should only know of what is in its layer and the one below, but never above. There is a caveat to that and that is what I use the Services layer for, It crosses all layers. I also utilize Interfaces.
You mention Architectural Sinkhole anti-pattern for layers that do not do anything. I have had some developers say that about the facades and models in the application context layer. They want to just use the domain object in the business layer. Even though there is usually no specific logic in those objects, they basically exist for view consumption, they do serve a very important architectural duty in my opinion. I like for my Domain objects to represent the entity that they were built for, I like them to have all of the relationships to other domain objects they have in reality. This can make some domain objects heavy, well I do not want to send out to my view an object with a bunch of properties and all of their relationships. Let’s say I want to display a grid of parts and with Manufacturer. The Manufacturer is a “has a” relationship. I would just have a Model that had the fields I needed and it just populate itself from the complete Part domain object. There shouldn’t be 15 different variations of my Part domain, there should be one. There might be 15 different facade or models. But I like to keep those limited also. Meaning if that if the difference between two models is just one of two fields, I will combine and just send the extra data. The other thing that using Facades and Models gets you is if you want to make design changes to the Business Domain, but have a lot of different applications utilizing some of those domains. The Facades and Models give you a layer of abstraction so you can change the underlying structure and never break the contracts you have with the layers above. So just because a layer might not do anything obvious doesn’t mean they do not have a purpose and should just be jumped over or never implemented. Sorry, I could go on and on about layered architecture. Anyone reading please utilize these concepts. This isn’t quick and dirty, it does add some time on the front end, but I have been utilizing these design concepts for almost 20 years and they have more than paid for themselves time and time again.