Advantages/disadvantages of a very fine grained modular ADF approach

Frank Houweling

unread,

Dec 16, 2016, 9:17:22 AM12/16/16

to ADF Enterprise Methodology Group

Dear all,

We would like your thoughts on advantages/disadvantages of a very fine grained modular ADF approach – a somewhat extreme variant perhaps of the pillar architecture.

Currently we are building a very large ADF 12.2.1 application (500+ screens, 500+ taskflows) and we are considering very small ADF projects (vs. medium sized ADF projects). Each logical set of functions results in one very small JDeveloper project and results in one ADF library that is consumed into the main application:

Very small projects each implement a single business function (one master-detail page, wizard or a logical small set of pages). This project consists of only a few EntityObjects, ViewObjects (mostly less than ten), one ApplicationModule and only a few taskflows – (± two or three). It feels like working with many simple, small HR ADF projects that are frequently used in the community to show examples.
We think we will end up with around 120 modules (ADF projects and ADF libraries)
It will result in many small ApplicationModules - we will use database connection pooling to use not more database connections than needed.

These very small projects can be developed, build, tested and released independently. The advantages we see (and have seen in the past):

It gives a developer a better code-overview (insight) and focus - because he develops in a simple, small project with fewer files.
Developing, building, deploying, testing small projects will go faster in JDeveloper because there is less to compile, build, deploy. More productivity. Same for maintaining the code.

This all versus medium sized ADF projects with ±50 EntityObjects, ±50 ViewObjects, one ApplicationModule and ± 25 taskflows.

Question:

What are your thoughts on advantages/disadvantages of this very modularized ADF approach?
Is many (100+) very small projects in an application better or worse in any way than fewer (15) larger ones?

Regards,

Frank Houweling

Chris Muir

unread,

Dec 18, 2016, 10:04:23 PM12/18/16

to adf-met...@googlegroups.com

Hi Frank,

In hindsight in developing the various ADF patterns some years back, I think in many ways thanks to the highly reusable platform ADF provides, we were exploring many of the ideas of "service based architectures" and "how large should your services be" from Martin Fowler's microservices movement (and SOA earlier than that too). Admittedly there is a difference between ADF and microservices, ADF being UI/flows + data services, while microservices is predominantly just data services, but they are still all services so parallels do exist.

Why I mention this is I think Martin Fowler has well articulated the concept of microservices and the challenges of service based architectures (being able to articulate the ideas to the wider community is one of his biggest skills imho), AND he has given thought to when to use them and NOT use them. And I think this has some parallels and lessons to be learned in a fine grained ADF architecture:

http://martinfowler.com/articles/microservice-trade-offs.html

Of specific note, Martin Fowler points out "Operational Complexity" as a key point to consider:

"Microservice proponents like to point out that since each service is smaller it's easier to understand. But the danger is that complexity isn't eliminated, it's merely shifted around to the interconnections between services. This can then surface as increased operational complexity, such as the difficulties in debugging behavior that spans services. Good choices of service boundaries will reduce this problem, but boundaries in the wrong place makes it much worse.

Handling this operational complexity requires a host of new skills and tools - with the greatest emphasis being on the skills. Tooling is still immature, but my instinct tells me that even with better tooling, the low bar for skill is higher in a microservice environment."

So as usual the answer to should you go for a fine grained ADF architecture (or microservices) or not is "it depends". If you have a senior well disciplined development team, go for it. Will the maintenance team beyond you have these skills? Be careful they can maintain what you've created. If you're just starting out, have not much experience in ADF or devops or continuous builds, don't mount more pressure on yourself than you need too when starting out, KISS.

In turn how large or small should your services be? Well that depends too where your operational boundaries lie.

This is why in the original ADF Angels in the Architecture presentation we were so cautious to recommend any one pattern over the other. One size doesn't fit all.

Of course I no longer work in the ADF space, and I'm sure ADF contemporary developers such as yourselves have a much better idea of what is and isn't possible with ADF today.

If I can add one final piece of potentially Aussie advice. Sometimes we over analysis this stuff and just need to get on with the job, make a decision, and live with the consequences, there are rarely perfect solutions.

Hope this helps,

CM.

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodology+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Florin Marcus

unread,

Dec 19, 2016, 8:08:20 AM12/19/16

to ADF Enterprise Methodology Group

When it comes to large ADF systems, my greatest concern relates to development productivity and I see ‘over-modularity’ as one major factor affecting it.

ADF Libraries are the most common way of separating an ADF application into modules, but modules should be loosely coupled.

For a more practical view on this matter, please think of a typical development lifecycle in ADF that comes in two flavours:

[Scenario A] Develop -> Compile -> Test in Browser

or

[Scenario B] Develop -> Compile -> re-Deploy (possibly restart WLS) -> Test in Browser

Now, if a developer spends 70% to 80% of the time doing [Scenario A], that’s what I would call a productive development environment.

But when [Scenario B] happens for more than 50% of development, the application development time doubles (at least).

So, smaller your modules, higher the chances of [Scenario B] type of development because developing Module A implies you testing integration with Module B.

So, Frank, I would favour 15 large ones over 100 smaller.

Thanks,

Florin

PS:

Keep in mind another key element here - JDeveloper comes with Working Sets. Which means you can have ONE single workspace for a huge application. I’ve heard that some Oracle Fusion Apps are configured this way.

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.

Jang-Vijay Singh

unread,

Dec 19, 2016, 8:34:33 AM12/19/16

to adf-met...@googlegroups.com

Hello,

Reminds me of the never-ending debate about granularity (first heard in SOA, microservices, ADF modules!).

The best of both worlds approach is for every module to be a self-contained unit that can be run in the integrated server before it's ready for a "common integrated" deployment

e.g. if an individual module is a task flow that will be incorporated in a bigger, common application after a server deployment, the developer responsible for the module could still have a local jspx page which you could run independently to just just your specific module.

During the initial productivity push, modularity might seem an overhead, but once something like this goes into production, it is valuable if you can build + test and deploy small (within reason) discrete and versioned components with little or no side effects on other parts of the application (e.g. using an approach where you don't deploy a big archive but multiple small ones, maybe with a versioned shared library approach, preferably without requiring server restarts)

The lifecycle of an application is not just an initial development but also incremental changes over its life in production. The application (or more specifically, its discrete, small,versioned parts) need to be as responsive to change as possible. It could mean a larger, more frequent number of releases rather than waiting for months to do a release only to roll back due to some module being buggy...

CommonUI v1.x.x->

-> shared-lib1 v1.x.y (task flow + EO + VO + jspx for integrated server use only)

-> shared-lib2 v1.y.z (task flow 2 + jspx for integrated server use only.)

if build x.y.z of any module breaks something, just deploy x.y.z-1 without affecting everything else that is unrelated...

I know I haven't really answered Frank's original question about the number of modules. It really is what makes sense in your context as others have pointed out - it's good that you can map a module to a functional use-case.

But another aspect might also be your team size (although that might not always stay constant).

Smaller standalone projects help avoid developers tripping on each others toes - if it's a 5 member team, you might still want to follow good practice with modularity but 500 modules might be over-kill.

Another aspect is your maturity of continuous integration processes, automated test coverage etc. If your modules are being automatically built and deployed to a common environment with every commit, you can probably afford more fine-grained modules. But if your build and deployment takes hours, you might re-think.

Too many variables! God luck!

JVS

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodology+unsubscribe@googlegroups.com.

Eric van Mourik

unread,

Dec 19, 2016, 9:16:19 AM12/19/16

to adf-met...@googlegroups.com

Hi Frank,

As Chris stated, the approach you describe has some similarities with a microservices based architecture.When we started our current project we faced the same considerations. We even thought about a setup where every taskflow was an application/project on it's own.

In the end, it all comes down to the question: Which kind of integration between the modules is needed and where are you going to put the complexity and effort to achieve that integration?

When the taskflows are predominantly autonomous and the main integration point is some kind of menu/master application that functions as the entry point for the end user, then a fine grained architecture will do. However, when the integration points between taskflows are less trivial - a lot of taskflow calls, taskflows embedded in other taskflows as region, etc. - then the integration is much easier to achieve when the taskflows concerned are in the same project. (Despite features as ADF libraries, remote taskflows, etc.)

So, a decision pattern might be to group taskflows that are likely to be integrated in an non-trivial way in the same application/project/cylinder/pillar/whatever you name it. And to separate taskflows that are unlikely to be integrated in a complex way. This might lead to a vast diversity in project sizes; let's call it the "Fitted for purpose" architecture.

Supposing you are using ADFBC, I think the placement of entity objects deserves some extra attention. Splitting an application in more and more (autonomous) parts increases the likelihood of multiple entity objects addressing the same database object across projects. As the entity object is the main gateway for all DML and related business rules, it might be beneficial in terms of robustness and maintainability to subtract them from the individual projects and centralize in some kind of common model project.

Regards,
Eric

--

Reply all

Reply to author

Forward