Just to add a little more to this post, I am winding down a project where we organinzed the solution by functionality. For example, we created a new project for each action (createItem, updateItem, confirmupdate, etc…). Each project had its own orchestration and transform map. All projects shared common schemas and pipelines, which were implemented as separate projects. Thus, our structure was as follows:
SampleSolution
SampleSolution.CreateItem
SampleSolution.UpdateItem
SampleSoluiton.ConfirmUpdate
…
SampleSolution.Pipelines
SampleSolution.Schemas
SampleSolution.Component
The rational for this solution structure was that we felt it would be easier to maintain if an action needed to be updated in the future. We would only need to replace the single assembly containing that action.
During development, we quickly discovered that each time we had to tweak a schema or pipeline, we had to undeploy each and every action assembly before we could deploy the update. This quickly became a rather tedious task. The Deployment Framework can simplify this task considerably, but you will need to make modifications for each solution you create if you use the approach I am describing. If you use the suggestion made by the instructor, however, you can use the Deployment Framework, essentially wothout modification.
In hindsight, my next project, I will structure my solution into BizTalk pieces, as mentioned, because I now realize the maintenance will essentially be the same, but deployment will be much simpler and less complex. (you still only need to redeploy a single assembly.
I hope this helps.
JimM