Web Application with Domain Entity Application Pattern

We created a Web Application with Domain Entity Application Pattern as part of our patterns & practices Application Architecture Guide 2.0 project.  The purpose is to show a baseline architecture based on patterns.

Scenario
Here's the backdrop we use for the baseline architecture:

Scenario

Pattern Solution
Here's our pattern overlay:

PatternsSolution (2)

Tech Solution
Here's our technology overlay:

TechnicalSolution

Application Pattern
You can review the full application pattern on CodePlex at:

Feedback

  1. What are 3 things you like about the approach?
  2. What are 3 things you would improve?
Published 21 January 09 07:01 by J.D. Meier
Filed under:

Comments

# J.D. Meier's Blog said on January 21, 2009 3:33 PM:

We created an initial set of Application Patterns as part of our patterns & practices Application

# Ryan Riley said on January 22, 2009 1:49 PM:

Thanks for posting these pattern baselines. They are very helpful for understanding, in brief, the patterns in the App Architecture Guidance.

I like:

1) the technology solution overlay for its description of the suggested technologies for each layer and pattern,

2) the use of domain entities and data mapper, and

3) the intended location of each layer.

I would make the following improvements:

1) "Domain Entity" makes me think of "Domain Driven Design" (DDD), but the inclusion of the Transaction Script pattern indicates this is not correct. Further, the Domain Entity and Repository pattern objects would normally fit into the BLL in DDD but instead are found in the DAL.

2) I am not sure what a "Facade Interface" means from the diagram. My thought is that you have an interface (the facade) and an implementation (the business process object).

3) Use of Entity Framework (and other O/R mappers with a Unit of Work pattern implementation, which is also missing from the patterns) requires careful management. To what level should the Unit of Work--in this case the ObjectContext--extend? My assumption is that each layer talks directly to the underlying layer and no further.

Thanks again for these pattern diagrams and the opportunity to offer feedback.

# Subrat said on January 25, 2009 2:18 PM:

This pattern does nto handle the sceanrio where we would liek to have 3 physical tiers for security peurposes. Wwb Tier, Application Server Tier and data tier with Web tier sitting in DMZ and Application and Data tier in secure zones.

What set of patterns should be utilized for that scenario.

# J.D. Meier said on January 25, 2009 2:34 PM:

@ Ryan

Good points and thank you for your feedback.

@ Subrat

You can roughly model from this pattern - http://www.guidanceshare.com/wiki/ASP.NET_1.1_-_Web_Services_to_SQL_Server ... while the technologies have changed, the core concepts are still there.

You can also browse here to get some further ideas:

http://www.guidanceshare.com/wiki/Category:Application_Scenarios

# Romi L. said on March 1, 2009 7:19 PM:

This pattern seems suited for my purposes where everything -database included- is to be created from scratch. Except the end users will be in other offices around the country.

Is the pattern still applicable if the server can be isolated from the rest of the company's network and only used for this application?

Furthermore, is there a reason why in this case the web and database servers should not be on the same machine?

Thanks...

# J.D. Meier said on March 1, 2009 7:34 PM:

@ Romi

You can use it as a baseline, but you'll want to spike on your high-risk scenarios.

Normally the database is factored from the Web server because of security reasons or an existing infrastructure.  For example, you have an existing database, but then you add a Web client that talks to the database.

# Romi L said on March 3, 2009 10:09 PM:

Thank you. I'm not an expert and though I understand the various scenarios, I guess I'm trying to figure out which way makes more sense.

For a small company with budget constraints, for an application that is self-contained, to be accessed exclusively over the Internet and needs no other network resources, I'd be interested to know what the balanced (risk/budget - and budget means both hardware and all software needed, plus the complexity of the app itself) option you think would be:

a. a hardware/software solution integrated in the main network - and that means a four-tier system is needed to protect the rest of the network

b. a two or three-tier system on a separate little network and I don't know what's involved in having another internet connection set-up

c. (and I might be completely off here) only  the software componment needed - i.e. could the app be hosted by a website hosting provider?

Thanks again...

# J.D. Meier said on March 4, 2009 1:16 AM:

@ Romi

I would explore hosting options.  If you don't have existing infrastructure and operations in place, I would compare hosting options that take care of reliability, performance and security.  Also compare which development environments they support.  Then you have a baseline to compare against your homegrown solution.

New Comments to this post are disabled

Search

This Blog

Syndication

Page view tracker