Add a comment

 

Re: Mapping software architecture to code

Hm... "a layer of controllers" doesn´t help with the deep nesting of logic "components". It just isolates them from some view layer. Asking "how many controllers per user story" to seems a violation of the principle of Separation of Concerns. User stories belong to the business domain. But controllers are part of a design pattern, they belong to the technical domain. So why should there be a specific mapping between user stories and controllers? If a user story is covered by just one view, it can be represented by the view´s one controller. But if a user story spans several views... it would need to be represented by several controllers, too, I´d say. (My premise: there is a 1:1 relationship between views and controllers.) That´s why user stories to me are not the starting point of agile design. They have to be broken up further. More tangible to users as well as developers are dialogs. So to me the question always is: What dialogs are part of a user story? (If you like think "view" instead of "dialog".) There is a n:m relationship between user stories and dialogs, I´d say. And the next step is decompose dialogs into interactions. An interaction is some sort of processing triggered by an event and transforming input into output. There is a n:m relationship between dialogs and interactions. Dialogs are naturally implemented as classes. And interactions are naturally implemented as functions. So with this kind of straightforward decomposition a set of hooks is designed onto which tests can be hung. The user story that way does not relate to a specific controller, but to a set of functions. And these functions are drawn together in tests. Thinking in terms of classes (or controllers) during design to me is a kind of premature optimization. Much energy can be spend on chossing candidate classes and distributing functions across them. That´s all technical detail not helping the agile cause, I´d say. Classes (interfaces) are an abstraction. If you have lots of stuff that somehow belongs together (high cohesion), then you might put it in the same class. But first find the heaps of stuff you can check for such patterns in the first place. Classes and components (as containers for classes) don´t come first - at least in my little design world ;-) They come last. No class ever has given a user any value. Only functions have. So that´s what agile design should lead to: from coarse grained requirements to finer grained ones (e.g. user stories) and then to even finer grained ones: dialogs and interactions. Because interactions are the root of all functionality we´ve to design. Get rid of starting with patterns like "layered architecture" or "MVC architecture". That´s secondary. Start with what users really care about: value provided thru increments. And increments are functions. Just my 2c.

Re: Mapping software architecture to code


Title
Body
HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).