4

I have built a server-side Java application of about 10k lines of code and on a code review a colleague made me notice that when developing a new business feature , I have to touch several files. My explanation is the following:

  1. In a well-layered architecture, delivering an additional business functionality might require small changes/additions to all the layers. For example in a classical three layer application which has a REST API/business logic/ data access layer, adding a new feature might require to touch these three layers.

  2. When developing a new feature you will easily get presented with the chance of refactoring existing code in order to keep the code in good quality(cyclomatic complexity, dependency tree length, etc) and DRY. Given that I have a test coverage between 70% and 80% I do that aggressively.

  3. Due to the small changes of point 2, I might have to slightly touch the tests for those features

  4. Because I touch N layers, I will have to update each unit test for each layer + at least one integration test

A different approach would obviously be to develop a more "componentized" application, where each business functionality is achieved through an independent module. Am I right in considering a layered architecture better, at least in containing the total cost of ownership and development of the application?

Improve this question
5
  • 2
    Well let's say you have a new business rules, which need you to add a new field in your business objects, you will have to touch multiple layers, you can't escape that.
    – Walfrat
    May 27, 2016 at 9:50
  • 1
    The right architecture-design depends on requirements. Due to requirements were not mentioned is going to be hard to say if your approach is appropiated or not. Layered architecures works really fine on projects where there're many integrations to do with another systems/apps/contexts, but modular architecture is no incompatible with such strategy. There're many factors that could make your choice appropiated but also unappropiated. Depends on requirements
    – Laiv
    May 27, 2016 at 9:51
  • thanks @Laiv what about answering with a comparison of strength and weaknesses?
    – Edmondo
    May 27, 2016 at 10:50
  • I would try, but I don't know your project's requirements. Despite so, as usual, in Software enginery there's no only one way to do things. There're as many ways as developers. As soon as your apps meets requirements and it's functional, we can say that, this argument is as valid as anyother. Beside best practices, patterns, trends and fashions, who need to prove that there's a better way is your collague ;-). You already proved that your projects works and do what it's expected. Isn't it?
    – Laiv
    May 27, 2016 at 12:53
  • You mention cyclomatic complexity. Presumably, you are talking about McCabe's metric. You should be aware that McCabe's Cyclomatic Complexity has been shown, on real code, to be VERY strongly correlated with raw SLOC, to the point that there is absolutely no value to be gained by computing McCabe's Cyclomatic Complexity, as opposed to just counting lines.
    – John R. Strohm
    May 27, 2016 at 22:59

2 Answers 2

Reset to default
3

A different approach would obviously be to develop a more "componentized" application, where each business functionality is achieved through an independent module. Am I right in considering a layered architecture better, at least in containing the total cost of ownership and development of the application?

If your "independent modules" or vertical slices each have their layers (i.e. for data, business, gui) you get the benefit of independence without loosing the advantages of a layered architekture.

In an online shop you may have slices for customer, product, product-availability, pricecalculation, orderprocess, payment, permissions, ....

However it might be difficuilt to make the slices independant of each other: Example: the pricecalculation needs infos about customer, product, product-availability

Improve this answer
1
  • +1. Independent though coupled services (slices) where the services are implemented using layered architecture.
    – Erik Eidt
    May 27, 2016 at 16:33
0

After to think about this question I wanted to share my point of view.

There's a sentence that reminded to me something that a Senior Architect told me once.

Here your sentence

I have built a server-side Java application of about 10k lines of code and on a code review a colleague made me notice that when developing a new business feature , I have to touch several files

Here what my collegue told me (more or less)

I have reviwed your projects. Overall those you took forward alone and I have noticed that your code (sometimes) is hard to read. Not due to spagetti code but for so many components. Often it's too abstract. Sometimes what customer needs is as simple as a rigid web app. Not a spaceship from NASA.

I have to confese that It hurts, but it was true. I do it So many times. Over engineering

So...

Didn't you, may be, make your app too complicated? I mean. Keeping layered design. Would you be capable to do it easier? May be you made too many, Service, Repositorios, configurations, components... Is there any window to improve or to make easier what now seems too much work. May be you tried to do it too abstract.

As I said on comments, I don't know what's your app for., So I hope nobody punish me for what I have just said.

"Componentizing" or not current solution. Choice (IMO) relies on app's nature and goals. Do you need it? Is this the way your app need to scale? Via modules, plugins, Addons ..?

What are you building? A framework? A lenguaje? A product that will allow 3th parties / community to dev their own modules or widgets? The company's lead product?

Or it's a simple solution for an specific problem/need which has been made with some minimums of qualitity?

There's no design that prevent you from to have work to do when new features are needed. Some request will attempt directly against the common sense that your design tries to bring to the madness/caos that some times sorrounds customers.

Summarizing. I think your arguments are as valid as any other in Pro of modular design. As soon as it works for you and do what it's expected, it's fine.

What matters and what can make you thing about to redesign would be that neither requirements nor goals are being achived.

I have not answered listing for and against of each approach, because that is something easy to find by googling a bit.

Hope it will helps.

Improve this answer

Your Answer

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

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