Here I will be suggesting some points to avoid some issues in future, which I observed during my work.
Suggestion1 : If you are following Agile structure, then you know many requirements can
change or you are allowing a scope of changes. Then try to first finalize the
basic or initial structure of the application, over which you will be building your
application later, like application server, technologies, scope of the
requirements. As I believe that in Agile such core things are not changed later,
though you can add these later as scope further increases. So have detailed
interview sessions with clients.
Suggestion2 : In Agile environment, when requirements are quite volatile & if scope is also
not getting decided, then avoid to introduce any design pattern at this time, as
later during implementation you may find some requirement not fitting in the
design pattern being followed.
Suggestion3 : If your application is making DB calls to insert/update the data, suppose you
have requirement where you are supposed to update the record if it exists else
insert the new record.
So I have seen people suggesting to make insert call first, & if it returns with
exception then do update. Or do update first & if it returns 0 records updated
then do insert. So in both the cases you will be making 2 calls in worst case
scenario. Such strategy is fine when you know that either you have new DB &
will be doing insert mostly or if DB is old then you know that you will be doing
updates mostly. But if you have probabilities for both then it is not the
approach you should follow.
Though its effect also depends on the cost of each DB call here. And plus if
you are handling exception here then its cost is also added.
So my suggestion is to pass the required information to DB & decide on such
operation on DB side only & this way you will be making only 1 call to DB & no
exception handling required for this here.
Approach 1 : Can you implement this logic of decision whether to update or
insert to some PL/SQL block like some procedure/function/trigger and this
must be handled with care also for not to update any unwanted record or you
get mutation error in trigger. You can write some PL/SQL block like -
BEGIN
INSERT INTO emp(empno, ename) VALUES (1280, 'SMITHA');
EXCEPTION
WHEN DUP_VAL_ON_INDEX THEN
UPDATE emp
SET ename = 'SMITHA'
WHERE empno= 1280;
END;
Approach2 : If can't write PL/SQL block on DB side or it is not feasible to
make changes in DB then check if your DB has something 'Merge' like it is in
Oracle which you can send to DB as a query & then Oracle will decide if data
needs to be updated or inserted. Below is one example -
merge into emp e1
using (select sysdate from dual) e2
on (e1.empno = 1280)
when matched then
update set e1.ename = 'SMITHA'
when not matched then
insert values (1280, 'SMITHA', 'CLERK', 7902, sysdate, 700, 100, 20);
In return of this statement execution you can get number of rows updated
or inserted. And this must solve your purpose.
Approach3 : If using any ORM tool/APIs then check the method or way it
provides for such scenario but avoid calling DB multiple times & handling
exceptions for such cases.
Suggestion4 : Select any design pattern very carefully or rather postpone such decision if the
requirements are not clear or complete or scope is not yet clear. Design
pattern is something which should come naturally during the coding rather you
enforce it. For the sake of the project cost & everyone's time don't push for any
design pattern till you have all the requirements clear with you & you know the
scope.
As later, any wrong design pattern decision will give a lot of pain due to rework
& sleepless nights.
Suggestion5 : Try to keep your architecture simple & light rather making it too fancy or loaded
with various technologies & APIs. Design your architecture in incremental
manner with bare minimum structure in the starting as it helps to maintain the
existing design, its easier to understand & its easier to modify/add new things
into it. It also helps others to understand about what is going on.
Suggestion6 : Have a look on my views.
Suggestion7 : Check the code where connections to DB or other systems are being opened.
See your developers are not closing those connections as part of finalize
method, as you never know when that block will be executed or even will it be
executed by GC. So better close these connections as part of finally block or
also make this closing activity a part of Shutdown hook as given here.
Suggestion 8 : If you are planning to introduce the MultiThreading, then think, think again.
See if you can delay the introduction of multithreading by postponing some
process. Multithreading looks cool & yes, maximum time it will be improving
your application's performance, but it is double edge sword which needs to be
used with utmost care & must be monitored. So try to consider YAGNI, SOILD,
DRY, KISS, SLAP & CAP principles properly not for the sake of meetings.
Suggestion 9: Don't try to fit every idea or way you saw in your earlier project or read
somewhere or heard from some of your colleague. For God sake, first try to
understand the requirements or existing System properly before you try to
apply your previous learnings.
Suggestion 10: If designing the application where you will be using
compression/decompression of files then checking about Google's Snappy
can be worthy. SNAPPY
Suggestion 11: If working as an Architect & trying to design some application, then never ever
think yourself smarter than the others & always keep your eyes, ears & mind
open to listen to others' ideas. You never know which random looking idea can
click the right chord to fine tune your design.
Suggestion 12: Before deciding to go on microservices path for your application design, first
understand the complexities & cost it brings in. Think about the database use
in your business flows, as your application code can be stateless but
database is all about state. So deciding to use microservices is easy but it is
quite difficult to remain on that road effectively & efficiently.
Suggestion1 : If you are following Agile structure, then you know many requirements can
change or you are allowing a scope of changes. Then try to first finalize the
basic or initial structure of the application, over which you will be building your
application later, like application server, technologies, scope of the
requirements. As I believe that in Agile such core things are not changed later,
though you can add these later as scope further increases. So have detailed
interview sessions with clients.
Suggestion2 : In Agile environment, when requirements are quite volatile & if scope is also
not getting decided, then avoid to introduce any design pattern at this time, as
later during implementation you may find some requirement not fitting in the
design pattern being followed.
Suggestion3 : If your application is making DB calls to insert/update the data, suppose you
have requirement where you are supposed to update the record if it exists else
insert the new record.
So I have seen people suggesting to make insert call first, & if it returns with
exception then do update. Or do update first & if it returns 0 records updated
then do insert. So in both the cases you will be making 2 calls in worst case
scenario. Such strategy is fine when you know that either you have new DB &
will be doing insert mostly or if DB is old then you know that you will be doing
updates mostly. But if you have probabilities for both then it is not the
approach you should follow.
Though its effect also depends on the cost of each DB call here. And plus if
you are handling exception here then its cost is also added.
So my suggestion is to pass the required information to DB & decide on such
operation on DB side only & this way you will be making only 1 call to DB & no
exception handling required for this here.
Approach 1 : Can you implement this logic of decision whether to update or
insert to some PL/SQL block like some procedure/function/trigger and this
must be handled with care also for not to update any unwanted record or you
get mutation error in trigger. You can write some PL/SQL block like -
BEGIN
INSERT INTO emp(empno, ename) VALUES (1280, 'SMITHA');
EXCEPTION
WHEN DUP_VAL_ON_INDEX THEN
UPDATE emp
SET ename = 'SMITHA'
WHERE empno= 1280;
END;
Approach2 : If can't write PL/SQL block on DB side or it is not feasible to
make changes in DB then check if your DB has something 'Merge' like it is in
Oracle which you can send to DB as a query & then Oracle will decide if data
needs to be updated or inserted. Below is one example -
merge into emp e1
using (select sysdate from dual) e2
on (e1.empno = 1280)
when matched then
update set e1.ename = 'SMITHA'
when not matched then
insert values (1280, 'SMITHA', 'CLERK', 7902, sysdate, 700, 100, 20);
In return of this statement execution you can get number of rows updated
or inserted. And this must solve your purpose.
Approach3 : If using any ORM tool/APIs then check the method or way it
provides for such scenario but avoid calling DB multiple times & handling
exceptions for such cases.
Suggestion4 : Select any design pattern very carefully or rather postpone such decision if the
requirements are not clear or complete or scope is not yet clear. Design
pattern is something which should come naturally during the coding rather you
enforce it. For the sake of the project cost & everyone's time don't push for any
design pattern till you have all the requirements clear with you & you know the
scope.
As later, any wrong design pattern decision will give a lot of pain due to rework
& sleepless nights.
Suggestion5 : Try to keep your architecture simple & light rather making it too fancy or loaded
with various technologies & APIs. Design your architecture in incremental
manner with bare minimum structure in the starting as it helps to maintain the
existing design, its easier to understand & its easier to modify/add new things
into it. It also helps others to understand about what is going on.
Suggestion6 : Have a look on my views.
Suggestion7 : Check the code where connections to DB or other systems are being opened.
See your developers are not closing those connections as part of finalize
method, as you never know when that block will be executed or even will it be
executed by GC. So better close these connections as part of finally block or
also make this closing activity a part of Shutdown hook as given here.
Suggestion 8 : If you are planning to introduce the MultiThreading, then think, think again.
See if you can delay the introduction of multithreading by postponing some
process. Multithreading looks cool & yes, maximum time it will be improving
your application's performance, but it is double edge sword which needs to be
used with utmost care & must be monitored. So try to consider YAGNI, SOILD,
DRY, KISS, SLAP & CAP principles properly not for the sake of meetings.
Suggestion 9: Don't try to fit every idea or way you saw in your earlier project or read
somewhere or heard from some of your colleague. For God sake, first try to
understand the requirements or existing System properly before you try to
apply your previous learnings.
Suggestion 10: If designing the application where you will be using
compression/decompression of files then checking about Google's Snappy
can be worthy. SNAPPY
Suggestion 11: If working as an Architect & trying to design some application, then never ever
think yourself smarter than the others & always keep your eyes, ears & mind
open to listen to others' ideas. You never know which random looking idea can
click the right chord to fine tune your design.
Suggestion 12: Before deciding to go on microservices path for your application design, first
understand the complexities & cost it brings in. Think about the database use
in your business flows, as your application code can be stateless but
database is all about state. So deciding to use microservices is easy but it is
quite difficult to remain on that road effectively & efficiently.
| 2003-martin-fowler-who-needs-an-architect.pdf |
I assume, if you have come to this end then you have understood all the above points & have understood what people are saying in the sessions above.
So check few more points below, & always know that being an Architect is not an easy job, one needs to be active on many fronts with responsibily -
Java Architect - Top 11 slacknesses or mistakes that can come back and bite you as an experienced Java developer or Java architect (java-success.com)
Worthy to have the below picture with you. These images are taken
OSI Model Layers and Protocols in Computer Network (guru99.com)
What is OSI Model | 7 Layers Explained | Imperva
Also have a look about the kind of attacks you should be aware about while developing application providing its services over the internet-
What is a distributed denial-of-service (DDoS) attack? | Cloudflare
OSI Model Layers and Protocols in Computer Network (guru99.com)
What is OSI Model | 7 Layers Explained | Imperva
Also have a look about the kind of attacks you should be aware about while developing application providing its services over the internet-
What is a distributed denial-of-service (DDoS) attack? | Cloudflare
When designing the web applications & after having understanding of above OIS layers, it is
always good to know more about what is going on in HTTP world & what data format or
communication channel or technology-
HTTP/2 vs HTTP/3: A comparison | Ably Realtime
HTTP2 Vs HTTP1 – The Difference Between the Two Protocols Explained (cheapsslsecurity.com)
always good to know more about what is going on in HTTP world & what data format or
communication channel or technology-
HTTP/2 vs HTTP/3: A comparison | Ably Realtime
HTTP2 Vs HTTP1 – The Difference Between the Two Protocols Explained (cheapsslsecurity.com)
