问题
I'm new to Biztalk. I wish to structure my artifacts into applications.
Should I go with one application per artifact type - for example 3 seperate applications, like 'BusinessProcess.Schemas', 'BusinessProcess.Maps', 'BusinessProcess.Maps', with all the assemblies related to these (typically just one), or do you think it best to just have one 'BusinessProcess' application, which would contain all assemblies related to the business process?
回答1:
Should I go with one application per artifact type
I think in general, you mean one project per artifact type? Although artifacts common to more than one application should be split out into a separate application / solution.
The rationale for splitting BizTalk projects up into component projects (and assemblies) is similar to any other .Net project - separation of concerns, isolation for testing purposes, independent versioning, etc.
Most of these are addressed in Erik Westermann's great answer here
One point that to elaborate on is that the dependency chain usually looks something like this:
Schemas (Internal / Canonical, External)
^
Maps
^
Ports + Pipelines
^
Orchestrations
(plus other miscellaneous .Net assemblies with helpers)
On a server with multiple applications deployed, at some point you'll likely need to have cross-application dependencies (especially if you have chosen to couple to definite schemas and not loosely couple e.g. via multipart messages), usually on Internal / Canonical Schemas which are common to more than one project.
Unless these schemas are separated from the other assemblies, any time a monolithic application changes, you'll need to go through the pain of uninstalling / reinstalling all dependent apps every time any change is made to the monolithic app. Generally because the whole enterprise is dependent on the Canonical schemas, they are carefully deliberated and thus fairly stable, whereas an app's maps and orchestrations are more likely candidates for frequent change.
Here's a structure for this scenario:
Separate Common / Base Solution Projects:
- Common internal schemas (event / EDA Meta information , internal errors etc)
- Canonical Domain schemas (i.e. the internal / enterprise model of Invoices, Claims, Transactions etc of your business)
- Helper assemblies for interacting with the above
Your application solution references the above, and then the commonly accepted separation is along the lines of the artifact types:
- External system schemas (if more than one, then each in its own assembly)
- Maps
- Pipelines
- Orchestrations
回答2:
It's really a judgment call. If you have large app with lots of Schemas, Maps, Orchestrations, sure, it makes sense to split them out.
However, small apps, 10 or so artifacts, not so much.
For a new BizTalk Developer, I'd stick with stick with one "MyBusinessProcess" app. At some point, you'll see an when a multi-Project solution starts to make sense, then do it.
来源：https://stackoverflow.com/questions/21781720/biztalk-applications-structure-how-to