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