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> >
