In a previous post about “the next generation software factories” I wrote about the factory meta model and it’s role in providing a better user experience for the factory user. A more detailed explanation of the factory Meta model, or better, Factory Product Model (FPM) can be found in this post on Jezz’s blog. We can even see an experimental version of an authoring tool for the FPM in this post.
All of the above mentioned posts are using screenshots of the EFx Factory as an attempt to explain the Factory Product Model concept and it’s potential. However, because EFx isn’t publicly available at this moment we reckon that missing knowledge of EFx and its underlying domain might be debit to understanding the ideas behind the FPM.
So, to solve this issue we decided to take the first official drop of Service Factory from p&p and use that as a test case for discussing the Factory Product Model and possible future authoring tooling. Most people interested in software factories should at least be familiar with Service Factory as an early example so we think we can use this factory and the problem domain it is solving as a good example.
In the next couple of posts we will define the FPM for Service Factory by first using an experimental version of an FPM authoring tool. Along the way we will describe the important concepts of the FPM and demonstrate what Service Factory could have looked like if it leveraged a FPM. We will also describe the relationship of the Service Factory FPM to its underlying physical solution structure and how all of this related to a fictional Factory Schema for this factory.
We will not only use this series of posts to share information to help peoples understanding of these concepts, but also to validate and refine our current thinking in this space so any feedback is highly appreciated!
Let’s start. The first thing to do when authoring a factory is to make sure we fully understand the problem domain the factory is supposed to solve. For the Service Factory, this domain is already well defined and is reflected in the Service Factory solution structure. We will use the following concepts from Service Factory in our discussions:
- Service Contract
- Service Interface
- Service Operation
- Message Type
- Data Type
- Service Implementation
- Business Entities
- Business Logic
- Data Access Logic
Some of the above Service Factory concepts are directly realised in the Visual Studio solution structure. Others, for example Service Operations, are “hidden” somewhere in a C# code file and can only be viewed by opening the physical file.
We will use the above list of concepts together with their physical representation (projects, source files) in Service Factory to model a FPM for Service Factory. We will then use this higher level abstraction of the Service Factory to see if we can further improve the factory user experience by driving Service Factory from this abstraction.
Stay tuned…