We need a discussion at the community level on how to do the issue tracking for Fineract and Fineract CN. Also because we have multiple repos, and we probably want to reference tickets when we make commits. Can you please hold off on making tickets for Fineract CN until we have at least the skeleton of a consensus on that?
Thanks, Myrle On Wed, Nov 15, 2017 at 8:25 AM, Markus Geiss <[email protected]> wrote: > (Sorry for the messed up format, sending it again:) > > Hey, > > mingeling two projects into one issue tracking system seems wrong to me. > > If you look at projects like Jackrabbit also maintaining 2 projects they us > separate issue trackers too. > > Given the code base is completely different and new I would not like to see > tickets popping up in the same system. > > Cheers > > Markus > > .::Yagni likes a DRY KISS::. > > On Wed, Nov 15, 2017 at 7:22 AM Markus Geiss <[email protected]> wrote: > >> Hey >> >> mingeling two projects into one issue tracking system seems wrong to me. >> >> If you look at project likes Jackrabbit also maintaining 2 projects they >> us separate issue trackers too. >> >> Cheers >> >> Markus >> >> .::Yagni likes a DRY KISS::.Given the code base is completely different >> and new I would not like to see tickets popping up in the same system. >> >> On Tue, Nov 14, 2017 at 11:55 PM Ed Cable <[email protected]> wrote: >> >>> 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 >>> <(484)%20477-8649> >>> >>> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org >>> <http://facebook.com/mifos> <http://www.twitter.com/mifos> >>> >>
