Add a comment


Re: An architecturally-evident coding style

I agree with your message: the code should mirror the design.

What I´m missing, though, in your drill down is carrying over the dependencies from the higher level of abstraction.

In your first image you show the core components to be dependent on three persistence media. But these dependencies do not show up in the second image. It´s not clear which of the core components use which persistence medium.

Also it´s unclear why there are components for GitHub, Job etc. No other component is using them.

And finally: I´m sure the architecture is trying to follow the SRP. What then is the single responsibility of the Activity Component. From the architecture I can see it has the responsibility to integrate several other components into a larger whole "process". Also, however, it seems to have an additional responsibility: to calculate some ranking.

I see 3 reasons for the Activity Component to change: 1. if the way the calculation has to be done changes. That´s a change to the domain of the component. 2. if one of its dependenies (e.g. Talk component) changes the way it offers its services, e.g. by splitting function f() into f'() and f''(). 3. if some service functionality is moved to another component, e.g. f() is moved from component C to component D.

The SRP states there should only 1 reason for a functional unit to change. But I see 3: one pertaining to the domain, two pertaining to structure (due to dependencies).

What do you think?

Re: An architecturally-evident coding style

HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
E-mail address
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).