James, I think it would be incredibly helpful if you could incorporate what has been discussed in this thread into a how-to on the wiki. The section you propose seems like an appropriate place for it. It would be a valuable part of the innovator's toolkit I'd like to see created to enable members of the community and ecosystem to come and innovate on top of the new micro-services architecture.
Just as we've had Ramesh contribute to improve the build documentation, I don't think we'd need any approval to add that documentation. If you can share with me your Apache ID, I'll grant you the necessary privileges to add/edit those pages. Myrle - regarding James's question regarding infrastructure, everything will still ultimately reside under the same FINERACT project at https://issues.apache.org/jira/projects/FINERACT, correct? There won't be a separate FINERACT-CN project, we'll just using labels to distinguish between issues right? If that is the case, I would say requirements can start to be added in the FINERACT JIRA with appropriate labels for CN. Ed Ed On Tue, Nov 14, 2017 at 2:48 PM, James Dailey <[email protected]> wrote: > 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 > > > > > > -- *Ed Cable* President/CEO, Mifos Initiative [email protected] | Skype: edcable | Mobile: +1.484.477.8649 *Collectively Creating a World of 3 Billion Maries | *http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos>
