Layered architectures and modular software

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?

5

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

1

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.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *