Hi Markus & Myrle Thanks for both of you jumping in on this thread. I think that the articulation you've laid out in your responses would be useful content here: ==> https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN
maybe as a child of https://cwiki.apache.org/confluence/display/FINERACT/Composing+a+Release+out+of+Microservices Could I help with that? i.e. *General Approach to a New Service * 1. How to think about a new service (is there a lot of overlap? first assess - as Myrle has done briefly for my trivial example) 2. How to build out a new service (creating it from template, start hacking as Markus described ) or (if completely new, following the architecture provided) 3. Structure of existing mifos-demo as starting point for understanding Do I propose that task somewhere besides the listserv? Secondly, this has given me some food for thought about how to write requirements for a variant of the functionality that already exists. Which JIRA issue tracking is in play for Fineract-CN? James On Tue, Nov 7, 2017 at 2:34 AM Markus Geiss <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> > > 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 > > >
