Hey,
I'd like to add a few things to Myrle's answer. (;
Given James' leasing sample is another type of loan, I completely agree
with Myrle
that this should be an extension to the already existing portfolio service.
This can be
accomplished by simply adding a new loan type to it. The design of
portfolio is based
on an SPI pattern, that allows you to implement your type of loan product
easily.
Saying this I'd like to use the chance to start a discussion about our
internal design
to be able to extract some educational documentation in the future.
NOTE: Just to be clear once more, this is not a recommendation to create
this type of
service, the whole functionality can and should be implemented using the
portfolio
service.
To design a new service we are following a three step approach which is
outlined as:
1) Define the domain
2) Clone the template
3) Implement domain specific functionalities
1) Define the domain
Based on Evan's Domain Driven Design[1], we shape every microservice based
on the
definition of a domain and the related bounded context. A possible leasing
service would
take care about all domain specific objects, and utilizes other domain
specific services,
e.g. customer, and accounting.
The leasing service would 'rule' over all domain objects within it's own
bounded context,
e.g. product definition, payment processing, product history, and stores
needed data in a
new defined database.
This provides a clean distinction between what is the job of the leasing
service and what
are the responsibilities of other, already existing services.
2) Clone the template
After the first design iteration is done, you simply clone the existing
template project and
follow the instructions found there. The template project provides a ready
made project
that follows our best practices service layout, and already has most of the
needed
plumbing built in. This allows you to focus on you requirements instead of
reinventing
the wheel over and over again.
3) Implement domain specific functionalities
Once you have cloned the template project and made it your own it is now
time to start
hacking away, focusing only on your needed functionality.
As Myrle already mentioned, based on the complexity implementing a new
service is a
matter of days or weeks, not months nor years.
Just to add a little of my own taste, I would suggest to always start with
a MVP (minimal
viable product) implementation to be able to collect early feedback from
your customers.
This allows you to adopt early and prevent unwanted surprises once you
release with a
big bang.
Cheers
Markus
.::Yagni likes a DRY KISS::.
1 - https://en.wikipedia.org/wiki/Domain-driven_design
On Tue, Nov 7, 2017 at 9:47 AM Myrle Krantz <my...@apache.org> wrote:
> Hi James,
>
> The service you describe as LeaseNow has a large overlap with the
> service implemented as portfolio. (1)
>
> Missing relative to your requirements list are:
> * aggregate payment information across multiple loans,
> * support for the dashboard you indicate,
> * outside payment connectors.
>
> Your "nice to have" (late fees) is already implemented.
>
> I do wish to eventually split that service into two: one focused more
> on the specific product (individual loans) and one focused more on the
> generic aspects of banking products in general. But for that, I need
> more than just one use case.
>
> This is a very sophisticated service. I've been working on it and on
> the services which support it for the better part of a year. In
> particular daily interest accrual throws up issues of synchronization
> and security which are hard to solve in a distributed computing
> environment.
>
> If on the other hand, you want to know how long it takes to create a
> simple service, some of our services were created in under a week. A
> service which saves very simple information, and which has only
> limited interaction with other services can be created very quickly by
> creating the template project you can find here (2)
>
> Since you described the boundaries of the portfolio service fairly
> precisely, I do believe you are thinking about services correctly.
>
> Regards,
> Myrle
>
> 1.) https://github.com/mifosio/portfolio
> 2.) https://github.com/mifosio/template
>
>
> On Mon, Nov 6, 2017 at 11:59 PM, James Dailey <jamespdai...@gmail.com>
> wrote:
> > hi Devs
> >
> > (This is about the new code, recently accepted, under the term
> Fineract-CN,
> > and is NOT about Fineract 1.x)
> >
> > Let's say I want to build a fairly lightweight service that calculates a
> > payment table for a customer and accepts payments. (maybe that is two
> > services) I'd like to use the newly accepted Fineract-CN code because
> I've
> > heard it uses microservices that can be put together in novel ways and
> thus
> > enable different kinds of financial service provisioning. Is there a
> > general approach to this, in this new development paradigm, that helps
> > answer the question: how long and how much effort to get to that new
> > service?
> >
> > Let's call the new service "LeasePayNow". The financial product is a
> > continuous payment, let's call it a lease payment. The consumer must put
> > something "down" (could be an up front fee) and then a payment plan is
> > provided from a menu of plans. The payments are recorded by the service
> as
> > they are received and compared against the expected payments. Late fees
> > may be added but that's a "nice to have" in our current thought exercise.
> >
> > The LeaseNowPay is dependent upon (relates to) a customer service that
> > manages the customers and holds status-of-customer information. It is
> also
> > dependent upon the outside payment connection(s)/connectors.
> >
> > Another service(?) LeaseNowPayDashboard displays the portfolio of the
> > LeasePayNow, an aggregation of all expected and actual payments and
> allows
> > for filtering and summation by segments. Some ratios and other
> > calculations can be done in the Dashboard.
> >
> > I'm looking for someone who can collaborate on this. But, first I hope
> > that I am thinking about the microservices and services concept
> > appropriately (smart endpoints, dumb pipes) and would like to hear back
> > from anyone who gets how this is put together.
> >
> > Thanks!
> > James Dailey
>
