Terminology

http://en.wikipedia.org/wiki/Greenfield_project

http://en.wikipedia.org/wiki/Brownfield_(software_development)

What is n-tier vs 2-tier?

http://en.wikipedia.org/wiki/N_tier

A lot of applications start off

With a 1 or 2 man team

As a 2 tiered architecture

Under what conditions does the need for n-tier arrise?

Questions

How do you evolve an existing 2-tier application to an n-tier?

How do you start designing a multi-tier architecture from the ground up?

What about question of scaling people

Spent some time defining multi-tiered vs. 2 tiered

Starts out as access implementation

Some manager wants to have multiple people using the application

Other stakeholders have unique requirements

Concurrent usage is one of the main drivers behind move to n-tier

Concurrent usage of data - problem becomes one of syncing caches

Current in terms of competing requirements

EntitySpaces ORM

What are the sources of concurrency problems?

Problems of concurrency may be problems of not having explicit workflow/domain services

I think there are 2 major problems where we run into concurrency

Implicit workflows

Poor definitions of aggregate boundaries - this results from data-centric thinking

Demand for n-tier was based on an access database not working

OSS project called interlinq? 

Serializes the expression tree ?

A bunch of discussion about patterns for using DataContext

One datacontext per application server

How do you successfully refactor the spaghetti code?

Look at the UI and figure out how to group all of the information so that the UI can make a single call to get the data (ViewModel)

So then how do you manage application concurrency issues?

Assumption is that this would be handled by the data layer - data would manage all queries/caching/concurrency

You shouldn't think about caching right away - caching is a performance tuning issue

If you have shared data, it makes sense to do it on the server side

As a general rule, caching on the client tends to make more sense from a scalability standpoint

Law of demeter

We shouldn't ever be thinking in terms of forms vs. web - it's all the same goodness

Our community, because Nhibernate was the first/only ORM out there, has developed some really bad habits

POO - plain old object

Most persistence layers out there want you to create your database first - that seems counter-intuitive

You should not have coupling between layers, either logical or in code

What happens if your aggregates have

Invoice

Line items

Line items are tied to a trade

Value the trade

As long as concurrency is controlled by the database, everything's fine

If you're trying to maintain concurrency across multiple distributed nodes, it becomes a lot more challenging

Interesting discussion around a trading application

Trades line items tie to statement line items

Therefore trades can be changing the statement line items after the statements have been finalized

How do you deal with a failure of the business analysis

One of the other problems may be that there's a single database for reporting and transactional

Separate out a separate, denormalized database and pull it out from the transactional database

Then the problem is simply an ETL problem

Recommended Reading:

Making explicit workflows - Udi Dahan is an expert on this topic

Instant replication

Clustering

ADO.NET sync services