Thoughts About the Architecture
Here is a thought area, defining how your application is architected has a huge impact on how changes are done, and how they affect the rest of the system. It will tell how difficult it its to add new thing, and how easy other people can cooperate, so this cannot be taken lightly at all. Hopefully we will have a sketch of how it should be by the end of this and later we can go further in the details, and specific changes.
The Key Ideas
Here are a few things that are desirable in a good system:
- Business logic have to encapsulated, bleeding of rules, make the system hard to maintain.
- Logic has to be reusable, duplication besides being hard to manage is also prone to errors.
- Logic has to be granular, this promotes reuse, and also componentization (Lego pieces like Hanselman would say).
- Interoperability, the things you do could be reused in a series of systems/platforms, phones, other websites, win/Linux/mac apps, etc..
- Scalable, you never know when your site is going to became the next big thing.
- Extendable, it’s a given that new things will be needed.
A popular architecture that has these feature is SOA, some people would even say that if you are starting something new now a days, that you should without a doubt use SOA and nothing else. You should be able to find extensive content in the internets about it.
So there that’s what we will be doing. We will use services, for every part of the site internally and externally.
But How does That Work
Every little piece of the site, can be encapsulated into a WCF web service that could further be consumed by the site trough a common interface in a “Service Manager”, which has the responsibility of checking availability, and then execute the request and respond with the appropriate content.
Now is this easy? Not necessarily, the wrapping of this services in this “common interface”, should provide easy access, but will require lots of configurations. Each service would have a configuration file (read data store), describing what methods are available, and what parameters these expect. Further the manager would get the method to be executed, parse the parameters and then execute a call to the service asynchronously.
Looking at the picture above, you will see on the left side in shades of purple, the “Service Manager”, the discovery part is basically check the availability of the service, by asking: Is the API accessible? Once this is done, then the consumer (“Front-End”), can proceed with execution or gracefully fail by posting a message for example.
In some cases, you might not need a service or you are just consuming structure, like MVC or the menus, for example, so I represented those in shades of yellow.
The front end in light blue, because of the asynchronous nature of the “Service Manager”, could be entirely written in JScript, but not a must. JScript would allow a more responsive UI, creating more user satisfaction and easiness of consumption.
Last the red bar representing things that will be used in all layers, like authentication, logging, etc.
The Service Architecture
In the picture above you can see, on the top the more common design, where every component can be called from any of the clients, this might create complications when trying to make changes, compose other systems, or even scale some of the functionalities, since, the whole architecture is big block of functionalities.
If you look at some of IDesign documentations you will find that they recommend breaking the architecture in many little services, that would make the problems described above to go away. The addition of he Web API layer, is just a way of abstracting complications when clients communicate with the system, for that you might find different solutions out there (WCF Web API , Service Stack , etc.).
Notice that each service is self contained, it has its own database, business rules, that means that changes there will rarely affect the other systems, making this clearly a good way to promote composability, scalability, extensibility, etc., like we wanted in the beginning of this post.
Obviously this is still a maturing architecture, and as I said before inputs are welcome and I will update the article with more info as I get them.
Also I want to thank Balsamiq for the cool pictures I have on the post.
What’s next: Part 3
The Past : Part 1