My template that forms the architectural basis for many of my projects is continuously improved as my knowledge and experience increases. The latest version contains many of the patterns and practices that I have been using over the last year or so.
In fact, this is not so much of a template but more of a sample application. It is based on a camper van rental company (anyone one who knows me will know that this is something I briefly dabbled with before concluding my future actually did lie with software development after all). There is a front end for hiring, and a back end for logging pick ups, drop offs and maintenance.
The Domain Model still forms the basis of what I do, and while I am constantly on the lookout for alternatives when circumstances dictate, I still find that most of the time it is the default solution.
One change is that I have abandoned the Application layer (sometimes called the Service layer). I could no longer justify having this layer in code. The purpose of this layer was simply to load entities from repositories, call the business logic contained in the entities and then save them. The problem is that this just became another layer for business logic to seep into from the domain. This functionality now sits in the controller of the UI. Some may argue that this violates the Single Responsibility Principle, but pragmatism wins over ideology here. It only adds a couple of lines of code to the controller and ultimately leads to more maintainable code, which is more important than religiously adhering to design principles.
Here is a use case diagram of the functionality included:
I have used ASP.NET Identity, but at arms length. Authentication, including storage of the UserProfile, password encryption and cookie management is handled by ASP.NET Identity. However details about the user are stored within the domain model, and store a reference key to the ASP.NET Identity UserProfile. This is because the UserProfile object must inherit IdentityUser, therefore meaning the Domain would have to have a reference to Microsoft.AspNet.Identity.EntityFramework. My Domain references look like this:
and I want it to stay that way. What's worse, this dependency propagates through the entire project. Most of the assemblies end up needing a reference to it - not great. Also I like to keep my role/permission management within the Domain, as sometimes permissions are intertwined with business logic, as explained here.
Also, I have been working my way through the OWASP Top Ten, but this is far from complete. I will be blogging about these issues in future posts.
Another area that my work has been focusing on recently is the much forgotten area of accessibility, and in particular, the tailoring of websites for screen readers. There is barely a website on the internet that does not fall down in some way on this, partly down to lack of priority, but mainly due to lack of awareness. Also the technology is inconsistent and sometimes unreliable, and when you consider that instead of having to support x number of browsers, you are now supporting x number of browsers multiplied by y number of screen readers, you can begin to see the challenge. However, we have a moral duty to accommodate non-sighted users, and sooner or later, we will have a legal one (the physical domain have accessibility laws in the form of building regulations, so you can be sure that the digital domain will do soon as well).
The Web Content Accessibility Guidelines (WCAG) 2.0 are the accepted accessibility standards, and where possible, I have adhered to these. Of particular note is the accessible form validation summary, which will feature its own blog post in the future.