I concur. Let's not create a mess to clean up later. (Ed - Let's move that issue to a different thread.)
On Wed, Nov 15, 2017 at 12:16 AM Myrle Krantz <[email protected]> wrote: > 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> > >>> <(484)%20477-8649> > >>> > >>> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org > >>> <http://facebook.com/mifos> <http://www.twitter.com/mifos> > >>> > >> >
