Jeremy wrote “Don’t Let the Database Dictate Your Object Model mentioned that

Many, if not most, enterprise applications have both an object model and the database model. For the most part, convergent evolution will probably lead the two models to be very similar, but it’s potentially dangerous to constrain the two models to match perfectly because the two models reflect different concerns altogether.

* Database Model – When you design a database model you’re primarily worried about the best way to structure data for efficient storage and retrieval, while also enforcing data integrity rules

* Object Model – The object model is first and foremost concerned with modelling the behavior and business logic of the system.

Ideally, I’d like to work on these two models somewhat independently and allow both models to reflect their different concerns first, and each other second.

Actually when I start for a new project, I always consider Martin Fowler’s Patterns of Enterprise Application Architecture.

The most patterns I look up are Object-Relational Structural Patterns, Object-Relational Behavioral Patterns, Data Source Architectural Patterns and Domain Logic Patterns. Also I will reference Domain Driven Design Quickly which is a short, quick-readable summary and introduction to the fundamentals of DDD.

There is no universal architecture can contain all patters. Most projects are hybrid patterns and sort of experience.

Patterns in Enterprise Software
The books from Domain Driven Design
Domain Logic and SQL