{"action":"created","issue":{"url":"https://api.github.com/repos/oasp/oasp4j/issues/219","labels_url":"https://api.github.com/repos/oasp/oasp4j/issues/219/labels{/name}","comments_url":"https://api.github.com/repos/oasp/oasp4j/issues/219/comments","events_url":"https://api.github.com/repos/oasp/oasp4j/issues/219/events","html_url":"https://github.com/oasp/oasp4j/issues/219","id":74284589,"number":219,"title":"Using component facades","user":{"login":"MarcoRose","id":10845524,"avatar_url":"https://avatars.githubusercontent.com/u/10845524?v=3","gravatar_id":"","url":"https://api.github.com/users/MarcoRose","html_url":"https://github.com/MarcoRose","followers_url":"https://api.github.com/users/MarcoRose/followers","following_url":"https://api.github.com/users/MarcoRose/following{/other_user}","gists_url":"https://api.github.com/users/MarcoRose/gists{/gist_id}","starred_url":"https://api.github.com/users/MarcoRose/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MarcoRose/subscriptions","organizations_url":"https://api.github.com/users/MarcoRose/orgs","repos_url":"https://api.github.com/users/MarcoRose/repos","events_url":"https://api.github.com/users/MarcoRose/events{/privacy}","received_events_url":"https://api.github.com/users/MarcoRose/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":{"url":"https://api.github.com/repos/oasp/oasp4j/milestones/7","html_url":"https://github.com/oasp/oasp4j/milestones/oasp:1.3.0","labels_url":"https://api.github.com/repos/oasp/oasp4j/milestones/7/labels","id":1125332,"number":7,"title":"oasp:1.3.0","description":"","creator":{"login":"hohwille","id":1923119,"avatar_url":"https://avatars.githubusercontent.com/u/1923119?v=3","gravatar_id":"","url":"https://api.github.com/users/hohwille","html_url":"https://github.com/hohwille","followers_url":"https://api.github.com/users/hohwille/followers","following_url":"https://api.github.com/users/hohwille/following{/other_user}","gists_url":"https://api.github.com/users/hohwille/gists{/gist_id}","starred_url":"https://api.github.com/users/hohwille/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hohwille/subscriptions","organizations_url":"https://api.github.com/users/hohwille/orgs","repos_url":"https://api.github.com/users/hohwille/repos","events_url":"https://api.github.com/users/hohwille/events{/privacy}","received_events_url":"https://api.github.com/users/hohwille/received_events","type":"User","site_admin":false},"open_issues":9,"closed_issues":11,"state":"open","created_at":"2015-05-22T10:05:40Z","updated_at":"2015-06-19T09:33:36Z","due_on":"2015-06-29T22:00:00Z","closed_at":null},"comments":3,"created_at":"2015-05-08T08:35:04Z","updated_at":"2015-06-22T13:15:23Z","closed_at":null,"body":"From: Jörg Hohwiller\r\n\r\nwe are getting into very fundamental discussions about  architecture in general.\r\nFrom what I learned and what you can find on the web and books about architecture a DAO is responsible for the operations around one persistence entity.\r\nThat is what we are doing in OASP: One DAO per Entity.\r\nThen in simple CRUD we have two Use-Cases per Entity UcFind<Entity> and UcManage<Entity>. However, this is a convention and you are free to extend to your needs. Business logic can get really complex and tough as we all know…\r\n\r\nWe used this design in Germany for years with great success and long before CobiGen was ever invented.\r\n\r\nFurther, the REST-Service Implementation is the same as the Component-Façade implementation. It is a Façade and has not real logic than delegation (and obviously protocol transformation). So I do not agree to your argument (from the earlier mail) that this is an asymmetric pattern.\r\n\r\nFurther to you and Simon:\r\nI learned that in the end it is simpler to have one pattern for all kinds of applications rather than saying well wenn its small and simple you do A and when it gets complex and big you do B. That is always causing more confusion and waste of design energy as you can never say when something grows from small to big or from simple to complex.\r\nMaybe in Germany we did so complex architectures in the past 15 years that this already seems so easy what we are doing in OASP.\r\n\r\nBut what does your components do and how do you tailor your components if there is one entity per component and all use-cases can be maintained in a single implementation class. If we are talking about a system with 1-10 entities we do not have to talk and care about architecture at all, that is peanuts.\r\nIn such case you would probably manage to maintain your system without layering and separation of components at all. Just use hibernate directly in your services. But when your system grows you will die!\r\nI am talking and thinking about bigger systems. And even when there are 50 entities and 200 use-cases I still consider a system as small.\r\n\r\nHowever, I totally agree to your suggestion that we should get more feedback from different countries, projects, developers.\r\nI have a strong personal opinion on these topics as you might read from my mails, but I am totally open hear what the community is saying and learn from it.\r\n\r\nFor me it was quite surprising that you all want to discuss about the approach 2. that was not in question for me at the beginning and I am still not convinced.\r\n\r\n-----------------------------------------------------------------------------------------------------\r\nFrom: Marin Soler, Angel Luis \r\n\r\nReviewing the sample application I see another \"anomaly\" to the pattern, let me explain:\r\n\r\n- The logic interface is nicely separated in UC and that way different teams can work on different classes\r\n- When doing the implementation, all the UCImpl refer to the same DAO, this way only one class is doing all the implementation of the use case. \r\n- Maybe this is only because it is the way CogiGen is generating the code but... shoudn't be there also different DAOs for each UC?\r\n   - If not, we can not use the argument of separate files to support different teams working on same location.\r\n\r\nI would vote for Simon proposal of starting small and having a chapter on \"how to scale\" where more advance packaging organization is used.\r\n\r\nWe should modify the generator for having this \"dual\" model... something I suppose won't be trivial.\r\nregards,\r\n\r\n----------------------------------------------------------------------------------------------------\r\nFrom Spielmann, Simon\r\n\r\nI was talking about the advantage of “grouping” all UCs into one componenten façade.\r\nThis allows to inject a single interface (the component interface) into other components. This is less work than injecting every single use case you need.\r\nThe bigger advantage is about readability. Since all uses cases are called on the components interfaces you could easily see which components they belong to:\r\n\r\nWith component interface:\r\n\r\ncustomermanagment.createCustomer(..)\r\n….\r\ncustomermanagement.assignCustomer(…)\r\n\r\nVs without component interface:\r\n\r\ncreateCustomerUc.create(…)\r\nassignCustomerUc.assing(…)\r\n\r\n\r\nFor the code completion. If you do completion on customermanagment you will the all UC-Method Customermanagement offers. If you don’t have this façade you have to browse to the customermanagement package and see what UC-Interfaces are there.\r\n\r\n\r\n-----------------------------------------------------------------------------------------------------\r\nFrom: Marin Soler, Angel Luis\r\n\r\nI can agree on the 5 minutes per component overhead... when writing.\r\n\r\nBut time is spent more time reading code than writing it and having all this model on the head is where I see the complexity.\r\n\r\nI don't understand well what you mean with less injection hazzle, and also the code completion advantage you mentioned... isn't it the same if you have one interface and implementation? use cases (as a group) doesn't show up on the IDE when the component interface is used (or I am missing something here)\r\n\r\nOther concern of mine is that this separation in UC is good for a project on a waterfall model where you have defined up-front almost all the project UC. But in a more agile environment you will be doing a lot of refactoring to re-group methods into new-or-renamed UC interfaces as project evolves... or you incur on the risk of ending with one interface for each method implementation in order to have greater flexibility (not very KISS)\r\n\r\nFor clearly seeing the advantages of the pattern we can also showcase the intended use of the individual UC on the sample application. Maybe I've haven't understood completely your ideas, let me share an example from the sample app.\r\n\r\n- In UcManageTableImpl there is a need for finding an opened order for a table. \r\n- In the sample, Salesmanagement is injected as a dependency\r\n- By having the individual UC... should have been better to have only UcFindOrder injected?\r\n\r\n-----------------------------------------------------------------------------------------------------\r\nFrom: Spielmann, Simon\r\n\r\nno time to start yammer discussion right now, but want to add some pro arguments for those facades:\r\n\r\nThey speed up development because of less injection hazzle\r\nThey greatly improve code readability because invoking use cases of other components is every explicit. You could nicely see which component offers the uc.\r\nYou could easily the which use cases offers a component (by code completion on the component interface)\r\n\r\nSo leaving out those interfaces could save maybe 5 minutes per component. I can't see a real efficency gain here.\r\n\r\n\r\n\r\n-----------------------------------------------------------------------------------------\r\nFrom: Marin Soler, Angel Luis\r\n\r\nI think you are right about scaling when it is a BIG application and there is a lot of people involved on the same project. \r\n\r\nBut we have to think also on smaller projects and free them for such added complexity. \r\n\r\n90% of our projects would be fine having one interface and one implementation. (Is this an Spanish singularity? how is it in other countries? or per engagement? maybe we need more information to better align the solution. )\r\n\r\nAlso, if we are exposing the interface through a service... we are already doing all the implementation on one single class!! (in this case OffermanagementRestServiceImpl). So \r\nwe are avoiding the problem in one layer but not in others... which makes it worse when trying to debug an application because it is kind of asymmetric. (Maybe we can think on having the components/usecases grouping also on client side)\r\n\r\nI think the problems about working on the same location should be easily managed as the code for each UC is quite contained and most of the time an automatic merge will do (theoretically, of course on real life there are always conflicts)\r\n\r\n\r\nSo... how can we offer a solution for large (or very large) projects and more contained ones?\r\n\r\nI think we can showcase both approaches on the sample applications clearly documenting which usecase (no pun intended) is trying to solve.\r\n\r\nI think this will impact also the as we should automate both alternatives.\r\n\r\n\r\n-----------------------------------------------------------------------------------------------------\r\nFrom  Hohwiller, Jörg\r\n \r\nwe should clearly distinguish whether we are going to question \r\n1.     the existence of the component interface and its implementation as a simple delegation façade\r\nOR\r\n2.     the existence of the individual use-case interfaces and their implementations\r\n \r\nWhen you are saying\r\n> In the simple example of Tablemanagement we would spare 3 interfaces. Do we need them for other reasons but to constitute the component façade?\r\n \r\nyou might imply 2. or you might not have understood the pattern and the code yet.\r\nFor me 2. is out of question as this would mean that the entire component implementation is forced to be in a single class.\r\nIMHO we should only discuss about 1.\r\n \r\nTo make things clear I just created a UML diagram with drag & drop from our offermanagement component.\r\n \r\n \r\nHere we have Offermanagement and OffermanagementImpl to be questioned by 1.\r\nIf we would drop this then other components using logic of the offermanagement component would have to inject individual use-cases. \r\nPro:\r\n•         We would save the upfront effort to create and maintain the façade.\r\nContra:\r\n•         We often might need multiple injections instead of just one and we have to find the one we actually need.\r\n•         If the internal structure (e.g. cut of use-cases) of the component offermanagement would change for some reason this would impact using components and hence might cause some extra effort.\r\n \r\nI personally think this is more a less a decision of flavor. For true KISS you could argue for 1. and it would not really hurt.\r\nAs you can see from the Contra side there are however few good reasons why the pattern was invented in Register-Factory (and we even improved and simplified the original RF approach that used redundant signatures between façade and Uc where we use interface inheritance also to centralize JavaDoc).\r\n \r\nHowever, 2. would mean to drop all Uc* classes and interfaces and have the ENTIRE implementation in OffermanagementImpl. This is a design hell that is not going to scale. Assume the developer conflicts when all are working in the same location. Assume the lines of code of that implementation and the effort to find the right spot to do a change.\r\nThis is massively violating Separation of Concerns.\r\n \r\nI hope the discussion is clear now.\r\n \r\nBTW: we tend to discuss too much via Email. Lets do all of this on yammer and where suitable in github issues instead.\r\n \r\nRegards\r\n  Jörg\r\n\r\n----------------------------------------------------------------------------------------------------- \r\nFrom: Rose, Marco \r\n \r\nSpanish team – out of experience with Devon Espana – questioned component facades for efficiency reasons and to simplify composing.\r\n \r\n(We discussed the benefits of the generator here already..)\r\n \r\nIn the examples, there is only little coding involved, still – what happened if: the component interface was only documented by the public methods of the implementing component class?\r\n \r\nIn the simple example of Tablemanagement we would spare 3 interfaces. Do we need them for other reasons but to constitute the component façade? \r\nIs there more discipline to design a quality component interface when one has to write an interface explicitly? (I’d say yes).\r\n"},"comment":{"url":"https://api.github.com/repos/oasp/oasp4j/issues/comments/114098845","html_url":"https://github.com/oasp/oasp4j/issues/219#issuecomment-114098845","issue_url":"https://api.github.com/repos/oasp/oasp4j/issues/219","id":114098845,"user":{"login":"hohwille","id":1923119,"avatar_url":"https://avatars.githubusercontent.com/u/1923119?v=3","gravatar_id":"","url":"https://api.github.com/users/hohwille","html_url":"https://github.com/hohwille","followers_url":"https://api.github.com/users/hohwille/followers","following_url":"https://api.github.com/users/hohwille/following{/other_user}","gists_url":"https://api.github.com/users/hohwille/gists{/gist_id}","starred_url":"https://api.github.com/users/hohwille/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hohwille/subscriptions","organizations_url":"https://api.github.com/users/hohwille/orgs","repos_url":"https://api.github.com/users/hohwille/repos","events_url":"https://api.github.com/users/hohwille/events{/privacy}","received_events_url":"https://api.github.com/users/hohwille/received_events","type":"User","site_admin":false},"created_at":"2015-06-22T13:15:23Z","updated_at":"2015-06-22T13:15:23Z","body":"> This should have the bad effect of introducing some redundancy on the sample because both AbstractComponentFacade and AbstractUC may have duplicated code.\r\n\r\nWhat would be duplicated actually? I do not yet see what you mean..."}}