This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have been doing java/j2ee for several years. Mainly I have focused on coding and sometimes I do UML diagram and database ER design as well. But I have not been in an architect role.
I am trying to push myself toward the architect direction (though I know I have to keep learning..). If you're an architect, can you share with me
1) some good j2ee desgin book 2) more importantly, usually what document an architect prepare/deliver when he/she starts designing a j2ee project ? Where can I find some online sample to learn and digest ? 3) any other tips will be appreciated.
The purpose of documentation is to communicate something to someone. So the right documentation is whatever tells somebody what they need to know. Who wants to read it and what do they want to learn?
Written documentation turns out to be a relatively poor medium for transmitting knowledge. Wouldn't it be better if you could stand at a white board and talk it through together? Video conference? Web meeting?
Bottom line is we can't give you a good "standard" or template for written docs. Figure out how they'll be used in your environment and what should be in them - if anything - will be clear. Sorry for such a non-answer.
Sun has a nifty set of J2EE patterns online and in money-for-dead-tree books. TheServerSide.com has several books online. For a more leading-edge view, look at Rod Johnson's Books about J2EE without EJB and J2EE with Spring. If you must have EJBs ook hard at a design with a single stateless session bean and a lot of POJOs.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
The best way to learn how to be an architect is by becoming one. On this occassion , there is no replacement such as reading books/document samples etc.,
And even worse, what is exactly expected from an architect in terms of documentation etc., could be different from one organisation to an other.
Anyway, to point you to a starting place, the best bet would be to gain access to all the architecture documents from all the projects in which you were a programmer/developer. Have a good read at them, and you will know what architects do and ofcourse plenty of templates from them.
After you have digested all of them and still not lost then you may try to appreciate the advantages/disadvantages in each of those architectures. And if you are really ready, just take the requirements document and create an architecture of your own and see how to compares to the one which are already implemented.
Hope that should start you off.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com