tag:blogger.com,1999:blog-5028009537158799436.post8281882514634994635..comments2023-07-10T04:50:03.236-07:00Comments on Building Real Software: DevOpsDays: Empathy, Scaling, Docker, Dependencies and SecretsJim Birdhttp://www.blogger.com/profile/17371102366836131341noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5028009537158799436.post-10464462239721486862017-09-29T15:36:48.590-07:002017-09-29T15:36:48.590-07:00It might not be so wrong to split it if each chann...It might not be so wrong to split it if each channel has different needs. This sounds like a classic case of trying to maintain a global domain model. It does depend, but you are in an enterprise environment rather than producing for public consumption. I've found that different departments in an enterprise have different definitions and completely different use cases/logic for the same entity (Employee for example). Perhaps you can make channel services that extend existing services when it becomes so much of a problem - better than fighting to maintain a globally unified model with irrelevant data and properties on it. Hope that helps ease the pain :)@philn5dhttps://www.blogger.com/profile/13741152072729675553noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-48597811332174726242017-07-27T12:58:56.280-07:002017-07-27T12:58:56.280-07:00In our enterprise, there are generic data services...In our enterprise, there are generic data services used by several departments. Each department asks for enhancements on these services.<br />There are times that the enhancements are finalised within the same week and to be released in that weeks release train.<br />But each department(user) wants to test it all to make sure the enhancement from other department did not break the service. <br />Thus, until both department's own QA agree on the results, the service can't be released. (Thus creating inter department decencies). <br />How to resolve this issue? <br />They ask me to split the service so that each channel has its own service to maintain. <br />But that is wrong approach as this will not be a generic micro service but project level service per user/customer. One option is to make one department to wait for the next release but that also delays the time to market. <br /><br />Is there any options other than using feature toggles? I think, toggles are difficult to maintain...<br />Thanks...Cengiz Kayayhttps://www.blogger.com/profile/09989946110412455728noreply@blogger.com