I am in the middle of creating a Bundle for PHP application based on Symfony 2.

I want the bundle to be clear and good designed, so I constantly move and refactor code, rename methods, reorder classes, move them to other folders, add some factories and adapters, proxies, and follow other oop design concepts.

I'm thinking if I should design UML diagram first, then start to work with IDE.

What is the best practice for designing good architecture?

When I start with draw of UML class diagrams before, then after coding, even with empty methods and tests first, I stop following the diagram I drew before, because I found it not matching what I need.

Can you share good practices for designing architecture for a libraries? I'm not talking about model (if so I could follow DDD).

  • 2
    Should you always start with a UML diagram? Only if you find that that's the method that works best for you.
    – user16764
    Feb 20, 2014 at 23:03
  • I don't think there is "one true answer" to this; I strongly dislike starting with an UML diagram, and would rather prototype first (and use UML afterwards to document), but I also know people who very much prefer to start with UML before starting to program... IMHO one of the biggest disadvantages of starting with UML is the tendency for everything to get too complicated than what it really needs to be... YMMV ... Feb 20, 2014 at 23:07
  • That tendency you mention is consequence of wrongly taking UML as synonym of Big Design Up Front. I find myself drawing UML diagrams on a daily basis, but just as support for the thinking process. Best to have at hand a whiteboard where you can freely do and undo, until you refine a design (subject to further evolutive and iterative refinement, of course) which you can then concrete into code.
    – rucamzu
    Feb 21, 2014 at 0:29
  • It also kind of depends what you mean by UML. I find the fullblown UML with annotations and whatnot way to heavyhanded. But UML lite on whiteboards with the rest of the team can be quite helpful. Feb 21, 2014 at 7:22

2 Answers 2


In a question is something should always (or never) be done, the only reasonable answer is: No, there are always exceptions.

Whether it is a good idea to start with a design in UML depends on the scale of the design, the ramifications if you get it wrong and your own comfort level.

If you do decide to start with an UML design, there are still two ways to use UML:

  1. As a specification language. In this case, the UML diagrams are a direct representation of your code and contain the same level of detail. Often, you can use RAD tooling to generate code from the UML diagrams.

  2. As a communication tool. UML is a powerful tool for communicating designs to others (or your future self), but there are no requirements that the diagrams contain all the minutiae in detail. For effective communication, it is often even better not to show all the details and that includes even stuff like helper classes or relations that are irrelevant to the point you want to make with the diagram.

If you use UML in the second way, then it is very much to be expected that the resulting code only looks like the diagram in broad strokes if you look from a mile away. Closer inspection will show large differences, but that does not necessarily invalidate the diagram.

  • +1, nice & concise (and showing up the misconception in the question that "there is only one way of using UML")
    – Doc Brown
    Feb 21, 2014 at 7:28

Apologies -- I'm going to say "I" a lot because I can only speak from my experience. Take "I" as a qualifier rather than the opposite.

Whenever I'm on a team that's really having trouble getting our arms around a problem, I draw sequence diagrams (http://websequencediagrams.com ROCK -- is it OK to mention them?). That defines the service interactions or the class interactions.

Coincidentally, the service interactions will define directly the API calls to implement, if I'm showing interactions between services. Or methods to implement if it shows interactions between classes.

(A lot of the data requirements also come out of that, but I have to admit that for brevity's sake I'm pretty good about capturing methods but not so good at the parameters.)

10 years ago, I used a UML modelling tool that would generate Java from the class diagram, so I would, in fact, generate a UML diagram up front. Well, at least at the same time I was writing the classes.

Since then, I very rarely do any UML diagrams besides sequence diagrams. Sometimes a straightforward entity-relationship diagram is useful if, again, the model is getting confusing.

EDIT: Actually, I draw state diagrams a lot. So state diagrams and sequence diagrams can be really helpful. I used to draw UML activity diagrams, too, but the sequence diagrams just kind of won out. Still, that defines the high-water mark. No else on the team is doing that level of diagramming.

It can be helpful to go the other way: run a tool that generates a class diagram from the classes. Whenever I do that, I always find modelling errors to fix. But that's just me. ;)

EDIT EDIT: BTW whipping out a nice sequence diagram in an interview can have big wow value. Even with non-technical interviewers. Just sayin'

  • Do you recommend good UML book? Feb 21, 2014 at 14:47
  • Sorry, but I learned most of my UML through the tools like TogetherJ (now Together Control Center owned by Borland) and sitting through heated arguments between $200-an-hour experts. websequencediagrams.com is pretty accesible to just start playing with. Other than that, just doing web searches on the different types of diagrams.
    – sea-rob
    Feb 21, 2014 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.