elcome back to my process of creating a new architecture. As you know, as I write this the creation process is not over, but is still ongoing. I’m changing things all the time which means the architecture is slightly different in every article. The good news is that nothing has been changed since the second part was written, but don’t expect it to stay this way.
In the second part (see the end of this article for endnotes) in this series I described the new architecture pretty much from a framework building blocks perspective, that is, I talked about some of the building blocks. (I said nothing about internal functionality, concentrating instead on external interfaces.) In this article I will change the approach and show how the architecture looks from a consumer perspective when solving a certain use case.
I believe that you will very quickly be able to tell from this article if you like the programming model or not. As I see it (and as I’ve said before), it’s very important that the programming model is simple for the client programmer, but it’s okay if the programming model is slightly tricky for the business tier and the database programmer. Why do I think this? Well, in my opinion the client programmer ought normally to focus on the user interface and the user interaction. If he gets a very complex API to use, it will of course require a lot of attention. There will also often be a great many views (forms etc) for one and the same part of the domain model. Duplication is automatically reduced if the code is written in the domain model instead.
This article could be read in isolation, but I do think it’s a good idea if you read part 1 and part 2 first.
The use case
The use case I’d like to use for my description is a registration of an order. The user of the application first gets the name of the customer. If the customer is found, everything is fine. If not, the customer is created. (Well, everything is still fine<g>.) Next, the user gets the name of the product they want to order and an order is created with just that single product. That’s it.
We could say that the use case has three parts:
- Finding (or perhaps creating) the customer
- Finding the product
- Creating the order
The Application Layer Class
The class in the application layer (or business fa