Hi Taher,
From my experience I have chosen OFBiz because the only "coherent"
framework with a data model and related services. Completely different
from all frameworks that are architectural only but remain an "empty
box" for building applications from scratch. I think there are many
developers who need a business application framework (with an underlying
data model) but they don't come close to OFBiz, I think because of the
complexity and being, paradoxically, too complete. For example, the zip
distribution already suggests an "all or nothing" use. Perhaps these
things do not bring new potential users of OFBiz closer.
I think that an OOP logic is perfectly compatible with the entity and
service engines, xml-dsl etc etc; indeed, they can be used as a basis to
create a higher level of abstraction, which through OOP makes it more
accessible.
With this I don't think of "changing" OFBiz for what it is, for the
backward compatibility and for the solidity of the solutions based on
OFBiz. It could be interesting, if there are interested community
members, to try a different path, with the solid foundations of OFBiz
but on a different paradigm. I don't know if this POC could be
interesting enough to become a sub-project or it could simply remain a
POC; but if anyone is interested it would be interesting to try!
Regards,
Nicola
On 03/04/22 19:12, Taher Alkhateeb wrote:
Hi Nicola,
Thank you for sharing your thoughts. It's good to have a practical
perspective.
If we try to maybe list what OFBiz offers as highest value (guessing
on behalf of folks) I would think it would include:
- The entity and service engines with their APIs
- The data model represented by entities
- The services that serve the data model
- The XML DSL that abstracts away the underlying technologies
(widgets, actions, entities, etc ...)
So OFBiz in that sense is a radical departure from OO since it all
depends on the abstractions of services (SAO) with an XML-based DSL to
manage everything. Maybe this is what people like or want the most out
of it.
So whether or not we should attempt a PoC depends on whether people
actually want that different architecture since a DDD perspective is a
significant shift (especially with bounded contexts in an OO style)
from what OFBiz offers.
Maybe more opinions here might shed light.
Cheers,
Taher
On 4/2/22 20:29, Nicola Mazzoni wrote:
Hi Taher,
I think it's a very interesting discussion. She made me think a lot.
I agree with your thoughts, but working as OFBiz "system integrator"
I fully agree with Michael.
OFBiz is not a ready-to-use ERP system but it is a fantastic
framework for developing custom ERP solutions. ERPs have a long, very
long life cycle and are less sensitive to technological innovations.
Often ERP and legacy are synonymous, while all the surrounding
applications change, the ERPs remain. My clients in Erp, as in the
"traditional" management of existing business processes, do not ask
for a "cutting-edge" system. Also working on the IBM mainframe I know
the subject, and I often suffer the consequences, not being able to
"move forward"
Since the beginning of 2022 I have had to take over the design "from
scratch" of a business application and lead a small DevOps team to
follow the development. I've waited 3 months to reply to your email
to share this new experience with a quarter of feedback behind it.
The project is not a "complete" ERP, but it is part of it. I didn't
start from OFBiz, it was a solution with technological requirements
very far from OFBiz and too tied to an already existing datamodel.
But most of all, I wanted to experiment with a new (for me) approach.
Just as OFBiz is closely linked to Len Silverstone's fantastic
"Datamodel resource book", I wanted to find Eric Evans' "Domain
Driven Design" as a "literary reference".
I don't like ORMs and therefore a very light persistance framework
(like MyBatis) has been used, keeping the queries "handwritten" and
not generated by the system. The goal was to make a completely object
oriented, clean and simple system, not heavily tied to any existing
framework. I followed the DDD approach (not in a dogmatic way ...)
avoiding any third party libraries (excluding Jackson, Apache
Commons, Apache Commons Pool, Apache CXF). I could have used Spring /
Spring data; but I didn't. I have nothing against Spring, but I would
like to use only frameworks that I know well, otherwise it is easy to
become a victim. I would never want to tell a client "you know, my
program is broken because there's something under the hood that I
don't know that doesn't make it work anymore"
In short? It was very interesting! The most significant effect (for
the development team / qa) was certainly the simplicity with which
the junior developers were able to be productive (having already the
object model done) by working on a clean and very readable code. In
general, the only drawback is a "structured" approach at the
beginning which certainly requires considerable design experience and
time. Precisely this, however, then allows an "agile" and very fast
approach in tests, in customer feedback, in reworks. I don't think
DDD (neither microservices, nor ORMs, nor noSql ...) is the silver
bullet that solves all problems. But we can intelligently take
advantage of these approaches without marrying them.
I think it would be very interesting if some community developer were
interested in creating a * small * POC of a DDD project. Using the
OFBiz Entity Engine by exploiting the DDD concepts and therefore the
generation of entity objects, value objects, repositories ... We
could take a "domain", then a small part of OFBiz data-model and
experiment with this approach. Leaving aside the graphical interface
part, focusing only on the core.
What do you think?
Regards,
Nicola
On 01/03/22 04:56, Aditya Sharma wrote:
Hi Taher,
Thanks for this initiative!
How about incubating it and adopting it as a subproject?
Thanks and Regards,
Aditya Sharma
On Tue, Jan 25, 2022 at 10:28 PM Eugen Stan<eugen.s...@netdava.com>
wrote:
Hello Taher,
Thank you for this initiative and sorry for not replying sooner.
I meant to reply for so long but life ...
I think most / all agrees that change is needed in OFBiz but I
guess we
have different ideas on how to proceed.
I don't think I can add a lot to what was already said.
I do think keeping the current number of git repositories is good.
More will add overhead.
I do believe that ofbiz should provide stable extension points so
people
can deploy their own plugins and functionality.
I'm also working on some ideas around OFBiz - I believe I can
re-implement OFBiz entity engine on top of relational algebra using
Calcite.
More on this soon on the mailing list.
Looking forward to seeing a PoC from you.
I hope we do get to improve OFBiz and make it even more appealing.
On 25.01.2022 16:29, Taher Alkhateeb wrote:
Thank you everyone for your kind feedback and sharing your
thoughts on
this initiative.
I didn't get enough feedback or momentum to give me the impression
that
this can be a community initiative. I think I made the discussion too
early before coming up with a PoC. So I will attempt something
privately
and come back perhaps when it is in a more ready state and see if it
garners any momentum. IF people are interested in collaborating, then
perhaps you can approach me and we can team up.
Thank you again.
Regards,
--
Eugen Stan
+40770 941 271 /https://www.netdava.com
--
*Nicola Mazzoni* | /CEO/CTO/
Mobile: +39 347 990 5529
*Mp Style srl*
Via Meucci, 37 | 41019 Limidi di Soliera (MO)
p.i / c.f IT03679300362
