How do you architect your systems?

[EdwardJS024]

Hi guys,
I am doing some research to learn how the members in this communty go about designing their applications. More specifically, does anyone here follow any specific principals in layering or partitioning of their systems?

If so, do you care to share your taught process on how you go about partitioning and delegating responsibility to different layers..

Edward J. Smith

 

[chiph]

I rely on these books a lot:
Patterns of Enterprise Application Architecture

Enterprise Integration Patterns

As well as the classic GoF book on patterns.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[dragonwell]

I primarily develop web-based, business applications so I use a pretty common 3-layer approach: UI, Business Logic, and Data Access. Also, because of this background, the data-access/presistence aspect of my architecture has received the most attention.

I have been using a generic Data Access layer (a meta-data driven object/relation mapper). The calls to data-access api are only executed in "manager" classes of the business logic layer, and never from the UI layer.

Classes in the BLL are grouped into two distinct types. The first group are what I would call domain-logic entities (customers, orders, producsts, etc) which have very limited responsibility pertaining to what they "are", and know about their parent and child classes when there are heirarchies in the domain. Classes of this group almost always mimic the database schema. Notably, these classes do not talk directly to the DAL - their persistence is handled by persistence-management classes.

The second "type" of class in the BLL are more functional classes which manage the persistence (and other processing) of the entity classes by providing a simple interface for the UI layer.

This is all pretty standard, I think. The primary deviance I think you will see when comparing the architecture I describe with others models, is that in my case my domain-entity classes do not manage their own persistence. For instance, you may see things like:

User u = User.GetNewUser();
//do stuff with u
u.Save();

but I prefer something like this:

UserManager manager  = BLL.UserManager.GetInstance();
User u = manager.GetUser();
//do stuff with u
manager.Save(u);

And the reason is that often the processing and persistence that goes on for the entities requires several differnet obejcts of different types to participate. I prefer a centralized manager to handle the transactions and so forth that are needed.

Thanks. Needed to get that in writing... ;-)


Share your knowledge! -

http://www.howisitdone.com

 

[EdwardJS024]

Hi Dragon,
I agree. Domain objects should not be responsible for managing persistence. They are strictly responsible for managing a business responsibility.

I have been following an approach very similar to yours using Repositories, which are collection like apis.

For example there will be a Movies repository that encapsulate all movies. Movies can be queried like:

Movies.FindByTitle("Gladiator");

or

Movies.Save(new Movie("Meet the Fockers"));

Movies has now become an integrated part of my domain, it's something I can speak about at meetings and reveals an intention with greater meaning than say talking about a DAO or some other technology-based term.

As for my architecture, I follow a Hexagonal model, and not so much a layered approach.



Jay Smith

 

[dragonwell]

As for my architecture, I follow a Hexagonal model, and not so much a layered approach.

Care to elaborate on that?


Share your knowledge! -

http://www.howisitdone.com