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[2] was written, but don’t expect it to stay this way.

In the second part[2] (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[1] and part 2[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.) 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:

1. Finding (or perhaps creating) the customer
2. Finding the product
3. Creating the order

The Application Layer Class

The class in the application layer (or business fa

The Consumer Code

Instead of spending a lot of talking, this time I’ll go directly to the code from my test class where I use the OrderRegistration class. I’ll take it from top to bottom, starting with the main method in Listing 1.

Public Sub AddAnOrder()

Choosing the Product

It’s time to look more at the code concerning the second part of the use case, that is, choosing the product. In Listing 4 you will find the _GetProduct() method.

Private Sub _GetProduct(ByVal productName As String)