├── .gitignore ├── 2014-12_11.DDDBE_11_Modellathon.md ├── 2014.12.04.SoftwareAsNewtonianPhysics.md ├── 2015-04-01-Legacy.jpg ├── 2015.09.22.RandomThoutghtsAbout5DaysDownTime.md ├── 2016.02.03.DDD.Epiphany.md ├── 2016.02.21.DDD_EventStorming_Cynefin.part.01.md ├── 2016.02.22.DDD_EventStorming_Cynefin.part.02.md ├── 2016.02.22.DDD_EventStorming_Cynefin.part.02 └── Cynefin-EventStorming.TheQuestion.jpg ├── 2016.02.22.TheImpact.md ├── 2016.02.22.TheImpact ├── TheSystem.01.Ideal.png ├── TheSystem.02.ImplicitUsers.png ├── TheSystem.03.WhenThingGoWrong.png └── Users.puml ├── 2016.03.11.DDD.Models.context.md ├── 2016.05.01.A_Letter_To_Pieter.md ├── 2016.07.06.CBA.md ├── 2016.07.14.DomainDrivenDesignResources.md ├── 2016.10.16.FeebackLoop ├── feedbackloop.2.png ├── feedbackloop.png └── feedbackloop.xml ├── 2016.12.12.DDDEuPreparation ├── Image003.png ├── Image003.tif ├── Image004.jpg ├── Image004.tif ├── Image005.png ├── Image005.tif ├── Image006.png ├── Image006.tif ├── Image007.png ├── Image007.tif ├── Image008.png ├── Image008.tif ├── Image009.png ├── Image009.tif ├── Image010.png ├── Image010.tif └── Stories.md ├── 2017-03-28.poetry.impermanance.md ├── 2017.02.11.Talk.Idea.Diversity.md ├── 2017.12.18.GesSystemProjections ├── 2018.02.10.AboutBoundaries.md ├── 2018.05.25.BaBeyond2018.md ├── 2018.06.02.After.6000.hours.and.31.years.md ├── 2018.10.19.kandddinsky └── TamedEventualConsistency.pdf ├── 2018.11.16.buildstuff └── TamedEventualConsistency.pdf ├── 2019.02.02.SpaConference.md ├── 2019.08.09_expectations_for_an_event_store.md ├── 2019.08.16_StormingWithStickies.md ├── 2019.10.24.CQRS.Onion ├── CQRS.Onion.Simplified.png └── CQRS.Onion.drawio ├── 2019.10.29.CQRS.md ├── 2019.11.13.Zelazny.md ├── 2020.01.30.Levitation.png ├── 2020.05.09.AnErrandOnQuestions.md ├── 2020.05.09.AnErrandOnQuestions └── trigger.png ├── 2020.06.16.ReactionToOverworking.md ├── 2021.04.05.AnOpinionOnSystems.md ├── 2021.04.05.AnOpinionOnSystems ├── AnOpinionOnSystems.drawio ├── AnOpinionOnSystems.html ├── cqrs_saving.02.png ├── cqrs_saving.png ├── cqrs_saving.svg ├── systems_01.svg └── systems_composed.svg ├── 2021.04.30.OnPrinciples.md ├── 2022.02.10_my_vs_ours.md ├── 2022.03.23_common_ground.md ├── 2022.03.23_common_ground ├── common ground.drawio └── common ground.png ├── 2024-02-19-EventStoreDB-typical-usage.jpg ├── LICENSE ├── README.md └── analysis.md /.gitignore: -------------------------------------------------------------------------------- 1 | **/thumbs.db -------------------------------------------------------------------------------- /2014-12_11.DDDBE_11_Modellathon.md: -------------------------------------------------------------------------------- 1 | # Random thoughts about DDDBE #11 meetup - Modellathon 2 | 11 December 2014 3 | 4 | Yesterday the [DddBe group](http://DomainDriven.be) held it's second offcial [modellathon](http://www.meetup.com/dddbelgium/events/219005772/). 5 | 6 | We were about 35+ people, grouped in about 8 teams. 7 | And I was the Domain Expert. 8 | 9 | 10 | ## What is Modellathon? 11 | In short, a hackaton but for models. 12 | In our case, there is no modelling technique imposed. 13 | 14 | Each group is allowed to use whatever means they find useful. 15 | More detailled explanations can be found here 16 | http://verraes.net/2013/09/dddbe-modellathon/ 17 | http://tojans.me/blog/2013/09/04/the-very-first-dddbe-event-the-modellathon/ 18 | http://www.jefclaes.be/2013/09/the-first-dddbe-modellathon.html 19 | 20 | I've seen Event Storming, plain drawings, UI Mockups, ER diagram, text, ... 21 | And all those techniques actually yielded some insight into the domain. 22 | Explaining some part of the domain in a very straightforward fashion. 23 | Proof that there is no One Silver Bullet modelling technique 24 | 25 | 26 | ## Running the modellathon 27 | It's important to timebox the modelling sessions. 28 | I think 15 to 20 minutes is a good length. 29 | 30 | Between the modelling session, 31 | have the facilitators ask for feedback 32 | and let the group express themselve on the experience. 33 | 34 | * It has allowed met to rest :-) for a few minutes. 35 | Being the domain expert is an exhausting assignement 36 | 37 | * It helped finding the groups that were in trouble 38 | , or that didn't have access to me yet. 39 | 40 | * It is a good moment to provide some more info to the all the groups 41 | either about the domain , or some modelling tips from the facilitators 42 | 43 | 44 | *Interesting twist* 45 | Leaving the models in place & switching teams 46 | You suddenly have Legacy models ! 47 | 48 | ## Being the Domain Expert 49 | 50 | If you ever want to take the role of domain expert for this kind of exercise 51 | make sure your are well rested, it is exhausting: 52 | lot's of talking and thinking about the domain. 53 | 54 | Take a real domain you have been working on 55 | 56 | Tell stories, many thanks to [Alberto Brandolini](https://twitter.com/ziobrando/) for the tip. 57 | Don't talk about your're own implementation 58 | 59 | You won't know everything, be ready to accept that and say: I don't know this 60 | 61 | ## What I gained as Domain Expert 62 | The domain I explained was quite broad. 63 | In facts, in the course of the project I'm working on , 64 | what is considered as the Core Domain has changed quite a few time 65 | This modellathon has forced me to remember 66 | the different Domains and business problems we are trying to solve. 67 | I was also offered the general overview of what has been built so far 68 | 69 | I also gained first hand experience on what is means to be a Domain Expert. 70 | What are the feelings real Domain Experts have when you have a bunch of 71 | IT minded people asking a lot of questions 72 | I only grasp now what it must be like to be invited, as a DA, to 73 | and [Event Storming](http://ziobrando.blogspot.be/2013/11/introducing-event-storming.html#.VImFN3tSI4Q) session. 74 | 75 | I think this kind of exercise might actually be a good way of running 76 | a post mortem on any project. 77 | In a couple of hours you get the whole picture again 78 | of the business goals and the project, 79 | and helps you realize if you've met them. 80 | 81 | 82 | 83 | 84 | 85 | 86 | -------------------------------------------------------------------------------- /2014.12.04.SoftwareAsNewtonianPhysics.md: -------------------------------------------------------------------------------- 1 | # Software project and Newtonian Physics 2 | I enjoy finding analogies between different context. 3 | I enjoy comparing software project to something else than 'Building a house' 4 | 5 | [So I tweeted this :](https://twitter.com/ylorph/status/540505860548481025) 6 | >Ec =0,5 mv^2 7 | >The biggest your team, legacy, scope & velocity. 8 | >if you're heading for a wall , it's gonna hurt 9 | 10 | 11 | Kinetic energy is equal to half of mass multiplied by the square of the speed 12 | http://en.wikipedia.org/wiki/Kinetic_energy 13 | 14 | This is also the amount of energy that you have to spend to halt some mass. 15 | Now , imagine if the halt is sudden, hitting a wall. 16 | The more mass or velocity the more energy released, 17 | the more potential damage 18 | 19 | So how does that apply to software projects? 20 | 21 | Most of us have seen projects fail. 22 | Some of them really badly. 23 | 24 | Which fail has hurt the most? 25 | The one you're still thinking about years after the facts? 26 | Even after all the rationalization. 27 | 28 | The ones, where I was a involved or witnessed, 29 | have always been the ones that 30 | * had too great a scope 31 | * had one, too big, team 32 | * had underestimated legacy systems 33 | * had too much money (!) 34 | * wanted to deliver too much too fast. 35 | In any combinations 36 | 37 | So If I make an analogy between 38 | * scope , team size and legacy as the mass 39 | * delivery as the velocity 40 | The more you have those , the more kinetic energy your project has. 41 | 42 | *The more potential damage you have if you hit a concrete wall* 43 | 44 | P.S. 45 | Of course all those failures lead to lessons learned... 46 | And next time we'll do beter, won't we ? 47 | 48 | 49 | 50 | http://hintjens.com/blog:100 51 | 52 | -------------------------------------------------------------------------------- /2015-04-01-Legacy.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2015-04-01-Legacy.jpg -------------------------------------------------------------------------------- /2015.09.22.RandomThoutghtsAbout5DaysDownTime.md: -------------------------------------------------------------------------------- 1 | # Random Thoughts About 5 Days Downtime 2 | Who said Network never fails ? 3 | 4 | ## Timeline 5 | 6 | 22/09/2015 7 | That dreaded late call, it's 22:00, one of the product owner calls. 8 | "We have a problem with the newly deployed features, something does not work, can you help ?" 9 | I get a summary of the problem and try to give some pointer as to how to solve it 10 | 11 | But one our later, ok it's time to head over there. 12 | I don't understand what they are saying over the phone 13 | and have to see a bit more information than I could remotely. 14 | 15 | Quickly seeing the exact error, it turns out to be simple. 16 | Some sources were not deployed on Production. 17 | Talks with the developer who stayed for the deployment 18 | He knows what has to be done, tomorrow I'm on leave. 19 | We quickly decide, with the product owners, to call it a day and that 20 | we can wait until tomorrow. 21 | 22 | Home 23 | It's really nagging me, we should have caught that on our QA environment, 24 | I take this as a personnal failure 25 | I fix the error. At this point I hate Dependency Injection 26 | It's 02:00 , fix deployed to QA & tested, 27 | Sending a mail to the System team, Dev Team & product owners saying it's fixed. 28 | They just need to deploy to Production. 29 | 30 | Meanwhile, we're out of business externally and internally, for a few hours . 31 | 32 | 23/09/2015 33 | I'm on leave today , caring for the childrens. 34 | Then again a call, in the late morning 35 | Product Owner : "It does not work, Production is still down, but it seems it's something else" 36 | Me : "I need to talk to the developpers and systems admin , for the exact error" 37 | Developpers & Systems Admin : "Database lock, caused by a transaction triggered by this operation, on Production & QA" 38 | Me: "Database lock there ? On Production & QA ? That should not happen, we fixed that a long time ago" 39 | I visualize the mental model of the code, ok... so this operations might indeed cause a transaction, but a long lived lock ? 40 | I give instruction on how to change the code. 41 | 42 | They fix it, and around tea time, get another call... 43 | Developpers & SysAdmins : "Ok, so the operation that caused a lock ... does not anymore" 44 | Me: "Cool" 45 | Developpers & SysAdmins : "but, we have other locks on the database. Caused by other operations" 46 | Me: "But those haven't changed for ages" 47 | Developpers & SysAdmins : "By the way...Production, QA and development are DOWN" 48 | At this point, having not slept enough, do not understand that. 49 | Fatal error not sleeping enough. 50 | 51 | Meanwhile, we're still out of business externally and internally for 1 day. 52 | 53 | 24/09/2015 54 | Yesterday the SysAdmins, Products Owners & Development team decided, 55 | even though not fully functional , to allow access to the systems internally. 56 | Some things do works sometimes. 57 | Externally minimal access to the system are granted. 58 | They also also implemented a manual process to allow other systems to be fed with 59 | the needed data from our systems, so that the business can still run , albeit suboptimal. 60 | 61 | Everybody is searching for the problem causing those database locks. 62 | First thing we do is list what has changed in the last few days. 63 | Our deployment from 2 days ago of course... 64 | but nothing in this code, or the deployment process itself could affect all environments in this way. 65 | 66 | Checking the logs...we find something like "the process could not access the Transaction mananager" 67 | 68 | Oeps... transaction manager in this case means DTC (Distributed Transaction Manager). 69 | At this point, well I already hated Distributed Transactions 70 | 71 | Our Web & App servers cannot access the Distributed Transaction manager. 72 | This point to a change in the network or the firewall... 73 | This is checked : no changes on any level of networking infrastructure can found. 74 | We check in realtime if all traffic is going were it should be and is not blocked by any firewall rules. 75 | No, all seems to be OK. 76 | We search, have friendly arguments, don't find any reason for all environments to be down 77 | By the end of the day, we find that 3d party systems are also having the same exact issue with DTC. 78 | We check , those systems haven't changed either. 79 | 80 | Time for Plan B. 81 | With the product owners, we review the list of the top features that have to be restored 82 | as soon a possible. 83 | Development will search for a way to avoid any distributed transactions in those code paths. 84 | 85 | System admins are still looking for the reason the DTC communication is blocked. 86 | I find DTCPing cumbersome to use , you have to open the application on both sides. 87 | every time you ping you have to close & reopen it on both sides. 88 | 89 | I quickly write a console app that check database connectivity & trigger a DTC . 90 | Way quicker to check for the sysadmins. 91 | 92 | 93 | 94 | 95 | Meanwhile, we're still out of business externally for 2 days, internally well it kind of works. 96 | 97 | 25/09/2015 98 | One of the system admins has a great idea: he moved one of the internal web servers from the firewall's WebServer Zone 99 | to the SQL server Zone. Guess what , it can fully communicate to the DTC servers located in the SQL server Zone. 100 | 101 | It definitively is a networking related problem, but why ? 102 | 103 | Our plan B proves to be difficult. 104 | 105 | 106 | 107 | 108 | Meanwhile, we're still out of business externally for 3 days, internally well it kind of works. 109 | 26/09/2015 110 | 111 | Everybody slept, we abandon plan B . 112 | We focus on the network. 113 | We don't find anything, the firewall logs are telling that no packets are dropped. 114 | It's getting late. We are losing hope. 115 | 116 | Since moving a Web server to the SQL zone seems to correct the problem 117 | we are thinking of moving all of them. 118 | But it proves difficult as well, some of the web servers & app servers are behind a load balancer. 119 | We have to reconfigure it as well. It's too many changes, error prone... 120 | 121 | Time for Plan B(s) 122 | - SysAdmins , instead of moving the servers from zone , will simply add a network card and have this NIC in the SQL server zone 123 | We tested that on one server & it actually works. The bonus being that we can appoly this solutions to other systems having problems as well.µ 124 | 125 | 126 | - Development will remove any trace of possible Distibuted transaction from the code. 127 | Downside, only our system will be available, and we don't know yet if we could suffer data loss & inconsistencies in the data. 128 | 129 | We are tired, we xwill do this in parallel tomorrow 130 | 131 | Meanwhile, we're still out of business externally for 4 days 132 | 133 | 27/09/2015 134 | Everybody is rested. 135 | SysAdmins are implementing the bypass , development is changing the code. 136 | 137 | The sysadmins wins...they finish first.. 138 | 139 | Meanwhile, we're in business externally and internally 140 | 141 | But we still don't know what the root cause is. 142 | 143 | 28/09/2015 144 | All systems are up and running, we do take the time to check anything that might have hung when we were down. 145 | Easy enough, we are using message queuing at key points of the systems. 146 | The messages have been patiently waiting for us to enable consumers. 147 | 148 | 149 | Meanwhile, we're in business externally and internally 150 | 151 | 29/09/2015 152 | 153 | Meanwhile, we're in business externally and internally 154 | 155 | 156 | ## Conclusion 157 | 158 | Many, many thank you to Christophe, Olivier, Pieter, Pierre, Tom, Inne 159 | Everybody was open to discussion, trying to find solutions. 160 | Helping to narrow down the problem & finding different ways to bypass it. 161 | No one pointing fingers at anyone. 162 | 163 | Many, many thanks to management, they have not been breeding on our necks. 164 | They remained hidden, because the product owners regularly provided information 165 | on what was going on & their understanding of the problem. 166 | 167 | Many, many thanks to our users, they stayed out of the way. 168 | I would have expected them to be nervous after the first day. 169 | But no, they were supportive and actually trying to understand what the problem was. 170 | 171 | On the human side, although an exhausting 7 days, this was a real eye opener. 172 | Quite a nice surprise to see that we have acted as one team. 173 | 174 | 175 | ## Post-Scriptum 176 | The problem was [....] 177 | 178 | ## TODO 179 | * Add business explanation drawing of bypass (the one with the roadblock, that you can use to explain to your non IT savy friends) 180 | * Add It explanation drawing of bypass 181 | -------------------------------------------------------------------------------- /2016.02.03.DDD.Epiphany.md: -------------------------------------------------------------------------------- 1 | # Random thoughts on a Domain Driven Design Epiphany 2 | 3 | I'm having a DDD [epiphany](https://en.wikipedia.org/wiki/Epiphany_%28feeling%29) 4 | 5 | Some of the pieces, of this complex model that DDD is, are suddenly fitting together. 6 | Quite nicely fitting together. 7 | 8 | I've been prototyping the model for a new piece of functionality, a completely new Bounded Context. 9 | And I'm in a state of flow doing this. 10 | 11 | Before the prototyping, we had a couple of [EventStorming](https://leanpub.com/introducing_eventstorming) sessions that allowed to discover the true nature of the problem space. 12 | I made point of creating a [context map](http://www.infoq.com/articles/ddd-contextmapping) 13 | And this is helping so much in the actual design of the model. 14 | The learning from the EventStorming sessions, the context map, they are _**in**_ the design and implementation of the 15 | model. 16 | The prototyping effort, is suddenly, not a prototype anymore. 17 | It _**is**_ the _actual_ thing, though incomplete, and some parts just left behind in the commit history. 18 | 19 | And, side effect, I'm in the [whirpool](http://domainlanguage.com/ddd/whirlpool/) 20 | The learning of the problem space, the strategic aspect, the design in itself. they are feeding each other with insights. 21 | 22 | Insights, in the domain (and that is the most important), but also in DDD itself which is a nice takeaway. 23 | 24 | 25 | The journey, up to now, has been long, full of side roads, shortcuts (please don't do that) and dead ends. 26 | The journey is still very long, still lot's of thing I'm not understanding or even misunderstanding. 27 | But it's such a wonderful road, full of nice surprises and full of great Human Beings. 28 | -------------------------------------------------------------------------------- /2016.02.21.DDD_EventStorming_Cynefin.part.01.md: -------------------------------------------------------------------------------- 1 | # Random thoughts on Domain Driven Design , EventStorming & Cynefin Part I 2 | 3 | This is a "gut feelings thoughts" post on how those 3 approaches & practices fit together. 4 | 5 | The gut feeling I have is that they nicely complement each other 6 | 7 | ## Disclaimer 8 | I've learned only recently of Cynefin ,thanks to the talks of Liz Keogh (aka [@lunivore](http://lunivore.com/) ) 9 | during [Buildstuff 2015](http://buildstuff.lt/2015/) & [Domain Driven Design Europe 2016](http://dddeurope.com/2016/) 10 | 11 | I'm only unlocking the power of Domain Driven Design strategic design. 12 | 13 | I have a huge positive bias towards EventStorming 14 | *** 15 | ## What I think is Common 16 | The three practices have in common an emphasis on managing complexity and making this effort explicit. 17 | And this for all parties involved. 18 | 19 | They share a set of fundamentals mantras: 20 | * Narratives are keys to understanding 21 | * People must be involved 22 | * People must share a common understanding of the problem space. 23 | * People should be allowed to experiment and fail safely 24 | * The outcome of experiments are used in feedback loops. 25 | 26 | They all have a set of practices to 27 | * Discover the current state of the problem space 28 | * Allow placeholders for the unknowns and unclassified issues 29 | * To classify problems 30 | * To move problems around. 31 | * To break the problems into smaller more manageable ones. 32 | 33 | ## Some Quick References 34 | 35 | Cynefin: 36 | [Cognitive Edge](http://cognitive-edge.com/) 37 | [InfoQ Cynefin mini book](http://www.infoq.com/minibooks/cynefin-mini-book) 38 | 39 | Domain Driven Design: 40 | [DomainLanguage.com](http://www.domainlanguage.com/) 41 | [Community](http://dddcommunity.org/) 42 | 43 | EventStorming : 44 | [Community](https://plus.google.com/communities/113258571348605620818) 45 | [The book](https://leanpub.com/introducing_eventstorming) 46 | -------------------------------------------------------------------------------- /2016.02.22.DDD_EventStorming_Cynefin.part.02.md: -------------------------------------------------------------------------------- 1 | # Random thoughts on Domain Driven Design , EventStorming & Cynefin Part II 2 | please read the disclaimer I made in [part I](./2016.02.21.DDD_EventStorming_Cynefin.part.01.md) 3 | Basically, Cynefin is new to me and I'm trying to make sense of it in relation to, for now, EventStorming 4 | 5 | Cynefin is a model and a set of practices that, as far as I understand, is meant to help decision making on an organizational level. 6 | It also is a way to achieve changes in organization. 7 | 8 | The practices seems to have the following properties 9 | * be oblique 10 | * avoid groupthink 11 | * use stories 12 | * participative 13 | * context / sharing 14 | * Emphasis on what then situation is _then_ change it 15 | * find the **most important problem** 16 | * invalidating ideas 17 | * breaking down silos 18 | 19 | An EventStorming session, by definition, 20 | * breaks down barriers & silos 21 | * has narrative & stories & anecdotes 22 | * is participative 23 | * ... 24 | 25 | An EventStorming session going well, 26 | especially a big picture one, will probably result in lot's of explicit unknowns and problems. 27 | And, hopefully, in finding the real problem that need solving, the bottleneck. 28 | 29 | Those certainly could be mapped on a Cynefin domain. 30 | This might help to decide what need to be furthered explored, or broken down (Complex -> Complicated) 31 | It will also uncover what parts of the organization and the people who are impacted and so help find out what & who can define the criteria for positive progress and improvements. 32 | 33 | ## Cynefin and EventStorming 34 | 35 | ![Applicabilty of EventStorming & Cynefin ](2016.02.22.DDD_EventStorming_Cynefin.part.02/Cynefin-EventStorming.TheQuestion.jpg "The questions I have") 36 | 37 | [TODO: I really should draw that differently...] 38 | 39 | ### Obvious 40 | [TODO ...a sessions explore the relation of the obvious to the rest, even in Big picture EventStorming ???] 41 | 42 | ### Complicated 43 | A Big picture Event Storming to explore different ideas and dismiss them or keep them for further exploration as fast as possible. 44 | 45 | More probably a set of Design level sessions. 46 | They allow quick exploration of different ideas. 47 | We can engage very specific people. 48 | We should prototype fast for rapid feedback. 49 | 50 | #### Complex 51 | [TODO well, we do get the whole picture , in all it's complexity. 52 | The whole is bigger than the sum of the parts....] 53 | 54 | 55 | 56 | 57 | #### Chaotic 58 | _chaotic for me = we're in a real mess_ 59 | I wouldn't EventStorm when in Chaotic mode. 60 | Chaotic mode is a call for action. Not for analysis. 61 | Using EventStorming to _retrospectively_ analyze what happened , yes definitively. 62 | Certainly because it is a group exercise and that we can explore different path and avoid groupthink 63 | 64 | #### Differentiating between ordered & unordered 65 | An EventStorming session could help here: 66 | Where we have lot's of scenarios, orange stickies, all coming easily: I feel that this could be in the ordered part of Cynefin (Complicated or Obvious) 67 | 68 | Where the scenarios are difficult, the events on the stickies are hard to find, lot's of different path, discussions, ... 69 | Probably Unordered domain (Complex / Chaotic) 70 | 71 | 72 | 73 | ## Some Quick References 74 | 75 | Cynefin: 76 | [Cognitive Edge](http://cognitive-edge.com/) 77 | [InfoQ Cynefin mini book](http://www.infoq.com/minibooks/cynefin-mini-book) 78 | [A Leader’s Framework for Decision Making](https://hbr.org/2007/11/a-leaders-framework-for-decision-making) 79 | 80 | EventStorming : 81 | [Community](https://plus.google.com/communities/113258571348605620818) 82 | [The book](https://leanpub.com/introducing_eventstorming) 83 | -------------------------------------------------------------------------------- /2016.02.22.DDD_EventStorming_Cynefin.part.02/Cynefin-EventStorming.TheQuestion.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.02.22.DDD_EventStorming_Cynefin.part.02/Cynefin-EventStorming.TheQuestion.jpg -------------------------------------------------------------------------------- /2016.02.22.TheImpact.md: -------------------------------------------------------------------------------- 1 | # Random thoughts on Who is Impacted by our work 2 | 3 | 4 | ## Our Ideal... 5 | ![The Ideal System ](2016.02.22.TheImpact/TheSystem.01.Ideal.png "The ideal world") 6 | 7 | 8 | ## But didn't we forget some users ? 9 | ![Implicit users](2016.02.22.TheImpact/TheSystem.02.ImplicitUsers.png "Some Implicit users") 10 | 11 | ## And when things go wrong 12 | 13 | ![When things go wrong ](2016.02.22.TheImpact/TheSystem.03.WhenThingGoWrong.png "Some more implicit users") 14 | -------------------------------------------------------------------------------- /2016.02.22.TheImpact/TheSystem.01.Ideal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.02.22.TheImpact/TheSystem.01.Ideal.png -------------------------------------------------------------------------------- /2016.02.22.TheImpact/TheSystem.02.ImplicitUsers.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.02.22.TheImpact/TheSystem.02.ImplicitUsers.png -------------------------------------------------------------------------------- /2016.02.22.TheImpact/TheSystem.03.WhenThingGoWrong.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.02.22.TheImpact/TheSystem.03.WhenThingGoWrong.png -------------------------------------------------------------------------------- /2016.02.22.TheImpact/Users.puml: -------------------------------------------------------------------------------- 1 | @startuml TheSystem.01.Ideal.png 2 | left to right direction 3 | skinparam { 4 | handwritten true 5 | ActorFontName Segoe Script 6 | RectangleFontName Segoe Script 7 | TitleFontName Segoe Script 8 | NoteFontName Segoe Script 9 | } 10 | title The Ideal World 11 | 12 | actor User 13 | actor Customer 14 | rectangle "The System" as TheSystem { 15 | } 16 | User -- TheSystem 17 | TheSystem -- Customer 18 | 19 | note "this is perfectly implemented" as PerfectNote 20 | note "I'm happy" as HappyNote 21 | User .. HappyNote 22 | Customer .. HappyNote 23 | PerfectNote .. TheSystem 24 | 25 | footer 26 | Copyright (c) 2016 @ylorph 27 | licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. 28 | http://creativecommons.org/licenses/by-sa/4.0/ 29 | endfooter 30 | @enduml 31 | 32 | @startuml TheSystem.02.ImplicitUsers.png 33 | left to right direction 34 | skinparam { 35 | handwritten true 36 | ActorFontName Segoe Script 37 | RectangleFontName Segoe Script 38 | TitleFontName Segoe Script 39 | NoteFontName Segoe Script 40 | } 41 | title The Ideal World\nWith The Implicit Users 42 | rectangle "The System" as TheSystem { 43 | } 44 | rectangle "The Explicit Users" as TheExplicits { 45 | actor User 46 | actor Customer 47 | } 48 | rectangle "The Implicit Users" as TheImplicits { 49 | actor Operations 50 | actor Helpdesk 51 | actor :Future Dev: as Dev 52 | } 53 | TheSystem -- TheImplicits 54 | TheExplicits -- TheSystem 55 | 56 | note "Any of them\n might be you" as noteImplicits 57 | noteImplicits .. TheImplicits 58 | 59 | 60 | footer 61 | Copyright (c) 2016 @ylorph 62 | licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. 63 | http://creativecommons.org/licenses/by-sa/4.0/ 64 | endfooter 65 | @enduml 66 | 67 | @startuml TheSystem.03.WhenThingGoWrong.png 68 | left to right direction 69 | skinparam { 70 | handwritten true 71 | ActorFontName Segoe Script 72 | RectangleFontName Segoe Script 73 | TitleFontName Segoe Script 74 | NoteFontName Segoe Script 75 | } 76 | title The World\n When Things Go Wrong\n Even More implicits Users impacted 77 | 78 | 79 | 80 | rectangle "The System" as TheSystem { 81 | } 82 | rectangle "Users" as TheExplicits <>{ 83 | actor User 84 | actor Customer 85 | } 86 | rectangle "Users" as TheImplicits <>{ 87 | actor Operations 88 | actor Helpdesk 89 | actor :Future Dev: as Dev 90 | } 91 | TheExplicits - TheSystem 92 | TheSystem - TheImplicits 93 | 94 | note "Any of them\n might be you" as noteImplicits 95 | noteImplicits .. TheImplicits 96 | 97 | rectangle "Family of" as TheFamily <> { 98 | actor :Future Dev: as DevFamily 99 | actor :Operations: as OpsFamily 100 | actor :User: as UserFamily 101 | actor :Customer: as CustomerFamily 102 | actor :Helpdesk: as HelpdeskFamily 103 | } 104 | rectangle "Friends of" as TheFriends <> { 105 | actor :Future Dev: as DevFriend 106 | actor :Operations: as OpsFriend 107 | actor :User: as UserFriend 108 | actor :Customer: as CustomerFriend 109 | actor :Helpdesk: as HelpdeskFriend 110 | } 111 | 112 | 'rectangle " Bosses" as TheBosses <> { 113 | ' actor :Future Dev's: as DevBoss 114 | ' actor :Operations's: as OpsBoss 115 | ' actor :Helpdesk's: as HelpdeskBoss 116 | ' actor :User's: as UserBoss 117 | ' actor :Customer's: as CustomerBoss 118 | '} 119 | 120 | 121 | 122 | note "The things going wrong\n in the system we delivered have \nan impact on those as well" as noteWrong 123 | noteWrong . TheFriends 124 | TheFamily . noteWrong 125 | 'noteWrong .. TheBosses 126 | 127 | 'TheBosses -right-> TheFriends : theirs too 128 | 'TheBosses -left-> TheFamily : theirs too 129 | 130 | 131 | 132 | footer 133 | Copyright (c) 2016 @ylorph 134 | licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. 135 | http://creativecommons.org/licenses/by-sa/4.0/ 136 | endfooter 137 | @enduml 138 | -------------------------------------------------------------------------------- /2016.03.11.DDD.Models.context.md: -------------------------------------------------------------------------------- 1 | # Random thoughts on Models And Context 2 | 3 | "All Models are wrong, some are useful" 4 | This saying as an implicit concept in it. 5 | 6 | Two examples : 7 | 8 | A very long time ago... 9 | I failed miserably a chemistry lab. 10 | The experiment was a fractional distillation of 11 | an [azeotropic mixture](https://en.wikipedia.org/wiki/Azeotrope) 12 | 13 | We had to draw the vapor-liquid equilibrium for the mixture. 14 | At the end of the lab, we show our curve to the lab masters... 15 | And they tell us , it's wrong... 16 | 17 | Why : we forgot to document the pressure in our drawing. 18 | Forgetting to put the pressure completely invalidated the experiment, because the curve was valid only given a known constant pressure. 19 | In other words 20 | The model we provided did not *document the constraints (the context) within which it is valid.* 21 | 22 | 23 | [classical mechanics](https://en.wikipedia.org/wiki/Classical_mechanics) and [quantum mechanics](https://en.wikipedia.org/wiki/Classical_mechanics) 24 | This one is easy... 25 | They both have mathematical models to describe the world. 26 | The classical mechanics is useful and good enough for some cases . see [Faynman physics lectures](http://www.richard-feynman.net/videos.htm) 27 | Quantum physics for other. 28 | 29 | 30 | 31 | So I propose that we make a slight change in the saying: 32 | 33 | "All Models are wrong, some are useful in a given context " 34 | -------------------------------------------------------------------------------- /2016.05.01.A_Letter_To_Pieter.md: -------------------------------------------------------------------------------- 1 | # A Letter to Pieter Hintjens 2 | 3 | Dear Pieter, 4 | I've met you in real life on Monday February 3, 2014 during one 5 | of the most memorable talk I ever saw about ... 6 | 7 | What was it again? 8 | 9 | About software, long lasting communities and simply(?) about life and the world. 10 | About how we should use our knowledge about the world to mold our activities, 11 | not fighting how it is, but trying to improve it. 12 | One Problem at a time. 13 | 14 | This talk, no, not a talk, a 3 hours long Conversation with the audience, has been a real eye opener. 15 | You actually managed to put into words some of the things I had felt, noticed 16 | , and did not understand for such a long time. 17 | 18 | 19 | Well technically the first time I met you was on Tuesday December 17, 2013: 20 | you came to check out our little DDDBe community. 21 | And you gently nudged us in a direction that I believe is the right one. 22 | That at least up to this moment, still is the right one for our little group and that we try to maintain: 23 | Be open, make sure everyone is welcome, beware the P's, and much more. 24 | So many things, in a few words you said at the time. 25 | 26 | Pieter, the last time I saw you, you said it was a strange thing 27 | that lot's of friendship with fellow countryman have blossomed during that conference in Lithuania. 28 | Even though we're all in the same country. 29 | For me it was even before that. 30 | The seeds of friendship have been planted well before that. 31 | 32 | 33 | You're a Gardener Pieter. 34 | You planted many seeds, in many places, all the time. 35 | Probably knowing that you would not be around to see most of the beautiful fruits and flowers of this work. 36 | 37 | 38 | Thank you, Pieter for telling us how to behave during your illness. 39 | Thank you, Pieter for taking the time to do all this. 40 | Many thanks. 41 | 42 | Yves 43 | -------------------------------------------------------------------------------- /2016.07.06.CBA.md: -------------------------------------------------------------------------------- 1 | # CBA ,Cost Benefits analysis 2 | 3 | Triggered by Greg Young's "Stop Over-Engineering" talk at 4 | Buildstuff Odessa, 5 | The recording is currently unavailable, 6 | Here another version of his talk at DDDx in London 7 | https://skillsmatter.com/skillscasts/8082-stop-over-engineering 8 | 9 | 10 | 11 | freq fail * (cost/fail) 12 | ------------------------ = CBA ratio 13 | (Investment / period) 14 | 15 | 16 | One of the cost of failure component at my current client is Reputation. 17 | 18 | Some of this Reputation loss definitively has 19 | a clear cost associated to it. 20 | For some other it is less obvious. 21 | 22 | Especially, because we have a lot more complaints about the systems in place. 23 | 24 | And the kind of complains (not complaints imho) we are getting do require a lot of analysis 25 | * to verify the claim 26 | * find out if they are substantiated or not 27 | 28 | This of course, from our point of view. 29 | And we take all of them *very* seriously. 30 | 31 | The worst I've had up to now was, at its core, about whether a mail was sent or not. 32 | That ended up with sending logs of the respective mail servers. 33 | And me explaining to business that SMTP does not guarantee delivery... 34 | 35 | The bizarre thing is that most of the complaints we are receiving are about parts of the systems that have not changed fundamentally for a long time. 36 | 37 | 38 | The question is what has changed then ? 39 | 40 | Recently ( a few month ago) we have been a lot in the news, there have been audits. 41 | The conclusion of the audits are, for as much as I can say, quite motivated and have a lot of nuance in them. 42 | But the abridged summary reported in the news, were done in a semi-sensational fashion. 43 | BAP has been literally ruling us for some time. 44 | 45 | So the cost per failure may have risen, the investment not. 46 | The frequency is definitively higher. 47 | 48 | The question that I have in my mind is 49 | 50 | Do we do something about it, in our systems, 51 | some of them Legacy that we'd rather not change. 52 | 53 | Or do we just wait for the storm to pass ? 54 | 55 | 56 | 57 | 58 | P.S. 59 | This is one of the reasons why my favorite topics lately is dealing with failures. 60 | -------------------------------------------------------------------------------- /2016.07.14.DomainDrivenDesignResources.md: -------------------------------------------------------------------------------- 1 | 2 | [Domain Driven Design Belgium Meetup](http://www.meetup.com/dddbelgium/) 3 | 4 | [DDD Europe 2017](https://dddeurope.com/2017/) 5 | conference in Amsterdam 6 | 7 | 8 | [DDD Europe 2016](https://dddeurope.com/2016/) 9 | lot's of recording available 10 | 11 | [DDD eXchange at SkillMatters](https://skillsmatter.com/explore?content=skillscasts&location=&q=dddx) 12 | talks recording from SkillMatters (you'll need to register to see them) 13 | 14 | [Domain Driven Design](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215?ie=UTF8&redirect=true&tag=domainlanguag-20 15 | ) 16 | By Eric Evans 17 | 18 | [Implementing Domain Driven Design](https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577 19 | ) 20 | by Vaughn Vernon 21 | 22 | [Patterns, Principles, and Practices of Domain-Driven Design](https://www.amazon.com/Patterns-Principles-Practices-Domain-Driven-Design/dp/1118714709/ref=sr_1_2?s=books&ie=UTF8&qid=1468496380&sr=1-2&keywords=domain+driven+design) 23 | by Scott Millett and Nick Tune 24 | 25 | [Event Storming](https://leanpub.com/introducing_eventstorming/) 26 | A book in progress by Alberto Brandolini 27 | 28 | [Living Documentation](https://leanpub.com/livingdocumentation) 29 | By Cyrille Martraire 30 | 31 | 32 | [The company site](http://domainlanguage.com) of Eric Evans 33 | -------------------------------------------------------------------------------- /2016.10.16.FeebackLoop/feedbackloop.2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.10.16.FeebackLoop/feedbackloop.2.png -------------------------------------------------------------------------------- /2016.10.16.FeebackLoop/feedbackloop.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.10.16.FeebackLoop/feedbackloop.png -------------------------------------------------------------------------------- /2016.10.16.FeebackLoop/feedbackloop.xml: -------------------------------------------------------------------------------- 1 | 7ZhNd6IwFIZ/Dcv2QCIRl1XbzqKzsufMOoUIOY2EiaHq/Pq5gcRCgzP26NT5cqHw3gSS97khVwI8W23vFa2KzzJjIkBhtg3wPEBoMiLwbYRdK4xHcSvkimetFL0KC/6NWTG0as0ztu411FIKzau+mMqyZKnuaVQpuek3W0rRv2tFc+YJi5QKX/3CM120aoLIq/6J8bxwd47IpI080fQ5V7Iu7f0ChJfNpw2vqLuWnei6oJncdCR8G+CZklK3R6vtjAljrbOt7Xd3ILoft2KlPqYDaju8UFHbqYOlazs2vXN+wDArc7jmZS7YjXE4wNNNwTVbVDQ1oQ0kAmiFXgk4i+BwP7cQTnJFMw6DmkkhFWilLKHXtIHlLA6v0XgSkf0niYlrYlMkvA7jMUkgw2yzEYYWS1nqO7riwmTbQ53yjMLwZzARaSbQxO0FohjOfZOsby9MabbtSNa0eyZXTKsdNLEJjcio7bLppEdooRad1MC2HbUZme8v9UoFDiyYYUhjD1KAiIAbTDP+0gNFvtYmc6YwC31FBc/LAN9AC9UMaB+Go9z+NpdZV7R02o5RtXYBGFk31pGbOzv1TbbA6GGhsjNlSDuLeTuFj4VtoyPL1bEfRR57kgywd9op7MlHst8w9vyf/Q/Zx/66x2iAfRyfzn7isc/ozn84//WWJ57l+zY9y9HplrsCpOP5HWOZ2dZBfZCy8v03C+6N0VrJZ/bG2SUX4oDZKZjFQJ8akziUITc2sOJZJg6R7eG8ACeMkh6oaBJ6oKJ4ABQ6w3Mx8iuXMz0YC1n3NsA/7Gnn8RugfPTSIwNEh3a60TmIxgNED9Shaa3EbqpgVTL9c/ObepxlJ6BQUlPNpZGuJqbf2tWjCYojgvEkIROURFDtXYRbNCZ9cKEPLo4GqlN0jmfmUI3yu4K7ABzsNiYHBx3FhozPUEJE/n+HR5o2e8wR+5hikOf0qWlgzKskL3UzmngaxHPjd62lXQtRx37BlnpgO9OyaivOFP5HPpqT+dXFVkwfCh7YvMiv2rsSD8pCK6pZztPeJtavvJ/UO2vxfwoodq+YHNAkPgoofj9QOH19Q9PEOm/B8O13 -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image003.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image003.png -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image003.tif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image003.tif -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image004.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image004.jpg -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image004.tif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image004.tif -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image005.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image005.png -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image005.tif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image005.tif -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image006.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image006.png -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image006.tif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image006.tif -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image007.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image007.png -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image007.tif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image007.tif -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image008.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image008.png -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image008.tif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image008.tif -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image009.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image009.png -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image009.tif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image009.tif -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image010.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image010.png -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Image010.tif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2016.12.12.DDDEuPreparation/Image010.tif -------------------------------------------------------------------------------- /2016.12.12.DDDEuPreparation/Stories.md: -------------------------------------------------------------------------------- 1 | * Let's Fail -- not all of us are doing 10^12 msg/Sec 2 | * who am I 3 | 4 | * Intro 5 | Not only a technical talk But want to show the impact of what we build on the business 6 | * Integrating with external third parties 7 | * getting information 8 | * Security 9 | 10 | * Are all messages equal ? 11 | * Are all messages of the same type equal ? 12 | * Soa, µSvc, integration all needs messaging of some sort, 13 | but since it's considered obvious (Cynefin) & supporting context (DDD),we can easily fall into Chaos (Cynefin) 14 | 15 | 16 | 17 | * Explain Original title => Messaging for the Middleman 18 | 19 | * Questions to audience 20 | * How many messages are you really doing per day? 21 | * Do we all do 10^12 messages day? 22 | * Can you do the quick math for the number of messages/hits you handle ? 23 | 24 | 25 | * make clear: using messaging as an excuse to tell the stories 26 | * make clear: the stories have a point 27 | 28 | * Stories 29 | * Leasing & latency 30 | * Logistics & Denial & Priorities are not the same when in chaos 31 | * Leasing & the cost & caching 32 | * HR: the switching switch & got queueing & snowballs ... 33 | * HR: 5 days Downtime! What is the business priority ? 34 | * Other client: can you define your problem in term of business? 35 | 36 | * in the end: feedback loop. 37 | * in the end: pattern language of failures ? 38 | * in the end: because we need to document this. 39 | 40 | 41 | * Mention Talks 42 | * Greg Young: "Stop Over-Engineering" 43 | * Greg Young: "Production issues", "Production Lessons" 44 | * Ali Kheyrollahi: "5 must-have patterns for your web-scale Microservices." 45 | * Ali Kheyrollahi: "From hard science to baseless opinions: where did we go wrong?" 46 | 47 | 48 | * Mention Books 49 | * Matthew Syed: Black Box Thinking 50 | * Jim Manzi: Uncontrolled 51 | * Michael T. Nygard: Release It! 52 | 53 | 54 | * Leasing 55 | * Business Case : about latency as business needs it 56 | * Business case: the cost of messaging 57 | * the cost of messaging 58 | * the case of the data provider cost that went up 59 | * latency & stale data (Eventual Consistency ?) 60 | 61 | 62 | * logistics 63 | * Business case 64 | * the case of the 3d party that wen mad which client is more important, is it the one with the highest priced message ? 65 | 66 | 67 | * legacy 68 | * Business Cases 69 | * replacing part of legacy 70 | * new features (no, problems solved) integrating with legacy * 71 | 72 | 73 | * Other 74 | * Business Cases : HR - Computer based tests 75 | * Security as an afterthought 76 | * it's about the API/protocol and the business problem it solves 77 | * Failures 78 | * from the network in between (NserviceBus) 79 | * from message handlers (NserviceBus). 80 | -------------------------------------------------------------------------------- /2017-03-28.poetry.impermanance.md: -------------------------------------------------------------------------------- 1 | # Impermanace and Time passing 2 | 3 | Jean Froissart( XIV century) 4 | 5 | ## Original Version (old french) 6 | 7 | On doit le temps ensi prendre qu’il vient, 8 | Toutdis ne poet durer une fortune. 9 | Un temps se piert et puis l’autre revient. 10 | On doit le temps ensi prendre qu’il vient. 11 | 12 | Je me conforte a che qu’il me souvient 13 | Que tous les mois avons nouvelle lune. 14 | On doit le temps ensi prendre qu’il vient, 15 | Toutdis ne poet durer une fortune. 16 | 17 | ## Modern French 18 | 19 | On doit le temps ainsi prendre qu’il vient, 20 | Toujours ne peut durer une fortune. 21 | Un temps se part, et puis l’autre revient. 22 | On doit le temps ainsi prendre qu’il vient. 23 | 24 | Je me conforte à ce qu’il me souvient 25 | Que tous les mois avons nouvelle lune. 26 | On doit le temps ainsi prendre qu’il vient, 27 | Toujours ne peut durer une fortune. 28 | 29 | -------------------------------------------------------------------------------- /2017.02.11.Talk.Idea.Diversity.md: -------------------------------------------------------------------------------- 1 | # Talk Idea: Diversity in recruitment 2 | 3 | note : 4 | Diversity in this context is about people with disabilities. 5 | Cognitive & physical disabilities. 6 | 7 | Abstract: 8 | TBD 9 | 10 | 11 | 12 | Main Goal: 13 | * We can do DDD even with a small team and too much work 14 | * No matter how small we can have impact on the business 15 | 16 | 17 | Type: 18 | * Experience report talk 19 | 20 | Challenge: 21 | * No Slides 22 | * do not make it a technical talk. 23 | 24 | 25 | Things to says: 26 | 27 | * Explain the Domain 28 | * as Alberto says: "Who's stupid enough to talk about his domain ?" 29 | * Domain was not complex, the right time to introduce some technical / design complexity (EventSourcing) 30 | * Explain the constraints 31 | * small team 32 | * shifting priorities (in the large) 33 | * How the team managed 34 | * to deal with the legacy 35 | * to deal with errors & upgrade of Events stream. 36 | * to deal with user expectations 37 | * BI needs (we could delay those ! ) 38 | * How we journey went. 39 | * explanation should follow the different releases. 40 | * some things I'm not happy about in the implementation 41 | * but we shipped ! 42 | * One of the most ethically rewarding project I've been on 43 | 44 | 45 | * Use the evolution of the context map with the releases 46 | 47 | * How the user put the requests on hold , so that missing info about reasonable accommodation in airport is up to end March 48 | 49 | * users saying themselves that some things should not be automated ! 50 | 51 | 52 | * AnySurfer compliance 53 | -------------------------------------------------------------------------------- /2017.12.18.GesSystemProjections: -------------------------------------------------------------------------------- 1 | # System Projections of GetEventStore 2 | 3 | * $by-category -> $ce-{category} 4 | * $by-event-tpe -> $et-{event-type} 5 | * $stream-by-category -> $categeory-{category} -> $@ contains the event that creates the category 6 | * $streams -> 7 | -------------------------------------------------------------------------------- /2018.02.10.AboutBoundaries.md: -------------------------------------------------------------------------------- 1 | # About Boundaries & Bounded Context 2 | 3 | 4 | So, in Domain Driven Design we have our problem space: 5 | * Domain 6 | * Sub Domains 7 | * Generic -------------------------------------------------------------------------------- /2018.05.25.BaBeyond2018.md: -------------------------------------------------------------------------------- 1 | # About Ba-Beyond and an EventStorming hands-on 2 | 3 | On 24-05-2018 I had the opportunity to do a small EventStorming hands-on during 4 | the first edition of [Ba-Beyond](https://ba-beyond.eu/) 5 | Here is my reaction on the same day [twitter://@ylorph](https://twitter.com/ylorph/status/999716762475204610) 6 | 7 | 8 | ## About Ba-Beyond 9 | 10 | Before I dive into my small retrospective, let's first see what this conference is about. 11 | Well the "BA" stands for _Business Analysis_, and some might think 12 | "Hey that's not your cup of tea, a conference about formal business analysis." 13 | The "Beyond" is what appealed to me. 14 | All the people I met at this conference are looking for ways to go further than formal or traditional analysis. 15 | They are actively seeking for opportunities to engage with the business and development team, sooner and in a more agile fashion. 16 | 17 | They see themselves as enabler of knowledge sharing and not only as knowledge scribe or requirement gatherer, passing the information form business to development. 18 | 19 | And that was refreshing. 20 | 21 | 22 | ## On a Big Picture EventStorming hands-on 23 | EventStorming is a lightweight workshop format intended to capture and visualize the domain of a business with all it's complexities and interactions. 24 | It was invented by [Alberto Brandolini](http://ziobrando.blogspot.com/search/label/EventStorming) with the aim of balancing out the biggest bottleneck we have in software development: learning and shared understanding. 25 | 26 | 27 | The conference foresaw talks of about 20 to 25 minutes, followed by 15 to 20 minutes of Q&A. 28 | 29 | At first I wanted to just do a talk on EventStorming, explaining the format. 30 | The organization then quickly asked to transform it into a hands-on. 31 | 32 | A hands-on of 40 minutes, and some time to steal on the coffee break. 33 | More of an EventStorming appetizer than a hands-on in reality :-) 34 | 35 | 40 minutes is not much at all, so there was a choice to be made on what to make apparent about EventStorming 36 | 37 | I limited the number of participants to 15. 38 | I got help for a business colleague (Yes a real, genuine Domain Expert) 39 | I prepared some A4 with a summary, big fonts, with a highlight of the Domain. 40 | 41 | I made perfectly clear to the attendees that they probably would not be able to run one themselves, but that they at least would get an idea whether 42 | 'This is for me' or 'this is not for me (_yet_)' 43 | 44 | The hands-on then, to my utter delight, went as any EventStorming session go: 45 | The facilitator (me) explaining what a Business Event is and pointing out that there is a timeline. 46 | I did put the first sticky myself. 47 | Then the, _normal_, few minutes phase where participants are clearly asking themselves 'What should I do , Why am I here ?' 48 | And then suddenly, stickies getting on the wall at a higher rate. 49 | 50 | That was about 20 minutes into the allotted time... 51 | We stopped I explained what happened, we quickly added some order left and right of some pivotal event. 52 | 53 | Then the discussion went on to the type of information that EventStorming allows to get that 54 | more formal workshop do not provide: 55 | * knowledge of how the people of the business interact with each other. 56 | * The personality type of the business people 57 | You could event find out if there is a dungeon master 58 | see ["The rise and fall of the Dungeon Master"](https://medium.com/@ziobrando/the-rise-and-fall-of-the-dungeon-master-c2d511eed12f) by [Alberto Brandolini](https://twitter.com/ziobrando) 59 | * Where they fit , as human, in the overall process as well as their knowledge of their own part. 60 | * Last but no least putting faces on a particular problems 61 | 62 | So, all in all, in 40 minutes it went way better than I expected. 63 | 64 | 65 | 66 | 67 | 68 | 69 | ### Resources about EventStorming: 70 | Alberto's book : [Introducing EventStorming](https://leanpub.com/introducing_eventstorming) 71 | Yes, it's only 60% finished, he's probably still working on it as you read this ... 72 | But this book is more than worth it's price, buy it, now ! 73 | 74 | [EventStormers Google Group](https://plus.google.com/communities/113258571348605620818) 75 | [DDD-CQRS-ES Slack](https://ddd-cqrs-es.herokuapp.com/) 76 | Don't hesitate to ask questions or share experiences on those 2 online communities. 77 | -------------------------------------------------------------------------------- /2018.06.02.After.6000.hours.and.31.years.md: -------------------------------------------------------------------------------- 1 | # 31 years and about 6000 hours later 2 | 3 | 31 years ago, it was on August 1987, I stepped into the dojo I've always been loyal to. 4 | And by the end of June, we will close it down. 5 | 6 | Time to look back and think about what I've learned. 7 | Because, without a doubt, the time I spent there and the people I met partly defined what I am today. 8 | 9 | There are many schools and ways of Aïkido, 10 | what made this dojo special is it's independence and openness towards others ways. 11 | There always was a will to learn from other without judging, trying to find the common ground. 12 | 13 | There are some schools who are rigid in their practice. 14 | There are some schools who claim to be the "true" way. 15 | I'm not judging this, it is an observation. 16 | I'd even claim that this is necessary for some people to learn, it gives them a clear path. 17 | But the truth is that rigidity and "true way" are just historical falsehood, when you know that they were founded by people who had learned from the original founder and left at one point in time to build their own school. 18 | So yes, they have a "true way", just the "true way" of a certain point in time. 19 | 20 | In my dojo I've been a student, I've been a teacher. 21 | And when my teacher died, we took over the future of the dojo. 22 | That is when I understood that **being a teacher is not about teaching what I know**. 23 | Teaching is learning: 24 | Teaching is being critical about what you believe you know. 25 | Teaching is being critical about the way you were teached. 26 | Teaching is findings ways to allow other to make their own journey towards understanding. 27 | Teaching is helping others find the keys that allow to learn further, without assistance. 28 | 29 | 30 | Those last 2 points are probably the one I care most about nowadays. 31 | 32 | The practice of Aïkido is codified. 33 | It might differ from school to school. 34 | But the underlying *principles* are, should, be the same. 35 | The actual body movements are dependent on a lot of factors, age, stamina, overall capabilities of one owns body, the other human being you're practicing with and lots of other factors. 36 | **But the underlying *principles* are the same.** 37 | 38 | One such principle has nothing to do with the mechanics & physics of the body. 39 | It's about respect. 40 | Respect of the other, regardless of sex, age, religion, capabilities, work, ... 41 | The list is endless. 42 | 43 | In a simplified way, when practicing we are subjected to an attack and we respond to it in various ways. 44 | What is special about what we do is that the response should not harm the other, it must convince the other of the futility of aggressiveness. 45 | The response should at one point in time, during the movement, reach a equilibrium where the attacker is given a choice. 46 | Either he tries to escape and will hurt himself, either he accepts the movement (being thrown away, some kind of lock , ...) and will end up *unharmed*. 47 | 48 | That is showing respect for the other and for oneself. 49 | For oneself, it is not allowing to be overwhelmed by the attack, responding in a way that is acceptable for one owns safety and the other safety as well. 50 | For the attacker, it is allowing him to have the choice of his own fate. 51 | 52 | That respect is about helping people being responsible for their own act and choices. 53 | 54 | 55 | Another point about teaching: 56 | In all those years, I've seen a lot of people coming into the dojo and leaving, very few staying more that a few years. 57 | 58 | Some have left because the way we teach did not suit them, they needed a real predefined path. 59 | That is not something we provided. 60 | That is ok , it's a choice. 61 | 62 | Some have left because their own life went in ways that did not allow them to continue. 63 | That is ok. 64 | 65 | There is less than handful who came into the dojo, stayed a few years. 66 | And then went their own way *but continued to practice*. 67 | I pride myself into believing that they were hooked into this practice thanks to me. 68 | Some have become far better than me at the practice. 69 | 70 | That is what teaching is about: giving keys, and hope that the other will be better than you. 71 | -------------------------------------------------------------------------------- /2018.10.19.kandddinsky/TamedEventualConsistency.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2018.10.19.kandddinsky/TamedEventualConsistency.pdf -------------------------------------------------------------------------------- /2018.11.16.buildstuff/TamedEventualConsistency.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2018.11.16.buildstuff/TamedEventualConsistency.pdf -------------------------------------------------------------------------------- /2019.02.02.SpaConference.md: -------------------------------------------------------------------------------- 1 | # About the SpaConference submission process 2 | 3 | Thanks to Nick Tune (@ntcoding) I submitted an EventStorming hands-on to 4 | the SpaConference in 2018 5 | 6 | And what I discovered there is a completely transparent process . 7 | Right from the start, you can see each and every one of the submissions. 8 | And anyone can comment on the submissions. 9 | This might sound scary, but all of the comments I have seen resolve around better submissions. 10 | 11 | Then a few week before the final decision is made, the submission are frozen, 12 | and anyone can again make a review. 13 | 14 | This time it's more in depth review, not just comments, like classifying the submission, 15 | wether it it's the SpaConference preffered format (workshop & hands-on) 16 | Those review are not public at that moment, you just know that a certain number of people reviewed. 17 | 18 | Once the review process is done , you get to see that actual reviews on you own submission; 19 | wheteher it has been accepted or not! 20 | This is an invaluable transparent process way better than 21 | "Sorry, You're not accepted, but try again next year" 22 | 23 | I understand that for larger conference it's impossible to give personalized feedback. 24 | But my guess is that the openess of this submission process must be scalable in some way. 25 | 26 | 27 | -------------------------------------------------------------------------------- /2019.08.09_expectations_for_an_event_store.md: -------------------------------------------------------------------------------- 1 | # Expectations 2 | 3 | What I expect from some system managing storage of streams of events, intended to be used in an event-sourced system. 4 | 5 | - ability to create streams 6 | - ability to delete streams 7 | - ability to use optimistic locking on stream level 8 | - ability to write a batch of events in one stream atomically and durably 9 | - ability to read events from one stream 10 | - ability to read all events in the store ( the so called "$all" stream) 11 | - ability to read forward and backward 12 | - ability to read from some position in a stream or from the "$all" stream 13 | - ability to remove events before some position in a stream 14 | - ability to remove events before some time 15 | - ability to have subscription (though I might consider it a bonus) 16 | - ability to read events from a stream in commit order 17 | - ability to read events from "$all" stream in commit order 18 | - ability to have metadata on stream level 19 | - ability to have metadata on stream level even if the stream does not exists yet 20 | - ability to have metadata on events 21 | - idempotent writes (more on that later) 22 | - support for high-availability scenarios 23 | - support for at least write quorums and causally consistent, monotonic reads 24 | 25 | other functionalities are bonuses, some bonuses are evil 26 | 27 | Examples of bonuses 28 | - ACL on streams 29 | - server side managed subscriptions 30 | - system streams 31 | - deleted streams 32 | 33 | Examples of evil bonuses 34 | - Transactional write on multiple streams: 35 | - you can avoid it by carefully designing your streams _[Note the year is 2024: I may have changed my mind about this since a few years ago]_ 36 | 37 | - allowing to participate in Distributed Transactions 38 | - e.g. writing to a stream and updating a read model in another storage atomically 39 | -------------------------------------------------------------------------------- /2019.08.16_StormingWithStickies.md: -------------------------------------------------------------------------------- 1 | # Event Storming and Modeling 2 | 3 | ## Big Picture Level 4 | 5 | Focus on the business (people) 6 | Mainly exploration sessions. 7 | Chaotic by design. 8 | There is no Scope. 9 | The format is flexible to adapt to the needs of the people. 10 | There should be discussions happening at all steps. 11 | 12 | Timing : 1/2 day to 1 day, more if the problem space is really large. 13 | 14 | ### Goals 15 | 16 | * Discovery of the domain. 17 | * Have people discuss conflicting views of the problem space. 18 | * Discovery of the Problem Space *as is* , whole of it . 19 | * Visualize & understand the issues. 20 | * Discovery of the most important problem to solve. 21 | 22 | ### Steps 23 | 24 | 1. Invitations 25 | 2. Room Setup 26 | 3. Kick-Off 27 | * What we're going to do 28 | * Prepare them for the awkward type of workshop 29 | 4. Chaotic Exploration 30 | * Let the people work alone, don't seek consensus 31 | * Iterate as needed. 32 | 5. Enforce the timeline 33 | * Locally 34 | * The whole 35 | * iterate as needed 36 | 6. People And Systems. 37 | * Who is doing what ? 38 | * What is the systems (internal / externals) 39 | * Only where needed 40 | * Iterate as needed 41 | 7. Explicit walk-through 42 | * Let the people tell their stories to the group 43 | * iterate as needed 44 | 8. Problems & Opportunities 45 | * Look at the red stickies 46 | * add "value" destruction & creation 47 | 9. Pick the Right Problem 48 | * Arrow voting 49 | 10. Wrap up 50 | 51 | 52 | ### Ingredients 53 | 54 | * Large Meeting Room ( no chairs ) 55 | * Huge Walls 56 | * Paper Roll (50 meters) 57 | * Flip chart (optional) 58 | * Healthy snack & beverage 59 | * People 60 | * with questions 61 | * with answers 62 | * 1 or 2 facilitators 63 | * ideally externals (they are allowed to ask stupid questions) 64 | * One is observing only & eventually takes over when the 1st one is exhausted 65 | * lot's of (whiteboards) markers 66 | * Stickies 67 | * Orange (squared , 500 ) 68 | * Blue (200) 69 | * Purple (200) 70 | * Pink (100) 71 | * Yellow (small, 200) 72 | * Arrows 73 | * ( green (100) ) 74 | * ( pale yellow (100)) 75 | 76 | ## Process / System Design Level 77 | 78 | Focus on the Solution. 79 | Less chaotic. 80 | Limited Scope. 81 | Precision required. 82 | Less people involved. 83 | This one is done when all 84 | * hotspots are addressed 85 | * path are complete 86 | * people are happy 87 | * people want to implement it. 88 | 89 | Timing : 1/2 day more if the problem is really large. 90 | 91 | ### Goals 92 | 93 | * Get into the details of the problem discovered during the Big Picture 94 | * Explore different possible solutions 95 | * Find an accepted agreement the solution that will be implemented in the solution space 96 | 97 | ### Steps 98 | 1. Explore the problem that need solving 99 | 2. Iterate over different solutions 100 | * Follow the color coding 101 | * people => command => Entity => Event 102 | * people => Command => ext. system => Event 103 | * event => read model => people 104 | * event => policy => command 105 | * draw mock-ups where needed 106 | * check the "value" creation / destruction 107 | * Address hotspots 108 | 3. Agree on "best" solution 109 | 110 | ### Ingredients 111 | * Large Meeting Room ( no chairs ) 112 | * Huge Walls 113 | * Paper Roll (50 meters) 114 | * A successful Big Picture EventStorming 115 | * Flip chart (optional) 116 | * Healthy snack & beverage 117 | * People 118 | * the relevant business experts 119 | * the development team 120 | * 1 or 2 facilitators 121 | * lot's of (whiteboards) markers 122 | * Stickies 123 | * Orange (squared , 300 ) 124 | * Blue (300) 125 | * Purple (200) 126 | * Pink (rectangular, 100) 127 | * Lilac (200) 128 | * Yellow (small, 200 ) 129 | * Green (squared, 100) ) 130 | * Pale yellow (rectangular, 100) 131 | 132 | ## Event Modelling 133 | 134 | Focus on the Solution. 135 | Less chaotic. 136 | Limited Scope. 137 | Precision required. 138 | Less people involved. 139 | This one is done when all 140 | * hotspots are addressed 141 | * path are complete 142 | * people are happy 143 | * people want to implement it. 144 | 145 | Timing : 1/2 day to 1 day. 146 | 147 | 148 | ### Goals 149 | 150 | * Get into the details of the problem discovered during the Big Picture 151 | * Find an accepted agreement the solution that will be implemented 152 | * Define chunk of independent work items. 153 | 154 | ### Steps 155 | 156 | 1. Brainstorm the Events 157 | 2. Create a story (timeline) 158 | 3. Wireframes / mockups 159 | * on top , swinlane per user 160 | 4. Inputs (commands) 161 | 5. Outputs (readmodels) 162 | 6. Conway's law 163 | * events in swimlanes 164 | 7. Elaborate Scenario's 165 | * State changes, commands 166 | * given - when - then 167 | * (event, event)=> (command) => (event) 168 | * State views, read models given - then : state: 169 | * given - then 170 | * (event, event) => (read models) 171 | * External state Input 172 | * given - when - then 173 | * (event, event)=> (command) => (event) 174 | * External state output s 175 | * given - when - then 176 | * (read model)=> (command) => (event) 177 | 178 | ### Ingredients 179 | * Large Meeting Room ( no chairs ) 180 | * Huge Walls , if they are writable , the better 181 | * Paper Roll (50 meters) 182 | * A successful Big Picture or Design Level EventStorming 183 | * Flip chart (optional) 184 | * Healthy snack & beverage 185 | * People 186 | * the relevant business experts 187 | * the development team 188 | * 1 or 2 facilitators 189 | * lot's of (whiteboards) markers 190 | * Stickies 191 | * Orange (squared , 300 ) 192 | * Blue (squared ,300) 193 | * Green (squared, 300) ) 194 | * Yellow (rectangular, 100) 195 | * Pink (rectangular, 100) 196 | * Lilac (200) 197 | * Pale yellow (rectangular, 100) (for the ) 198 | * A4 paper sheet (100) 199 | 200 | ## Dogmatic Color Coding 201 | 202 | | Color | Concept | 203 | | --- | --- | 204 | | Orange | Event | 205 | | Blue | Command | 206 | | Green | Read Model| 207 | | Yellow | Entity | 208 | | small Yellow | People | 209 | | Pink | System | 210 | | Lilac | Policy | 211 | | Purple/Red | Hotspot | 212 | 213 | 214 | 215 | 216 | ## Resources 217 | 218 | * https://www.eventstorming.com/ 219 | * https://www.eventstorming.com/book/ 220 | * https://www.youtube.com/watch?v=jFEC7Pb1FtM 221 | * https://www.youtube.com/watch?v=VXdvVo5Im6E 222 | * https://eventmodeling.org/posts/what-is-event-modeling/ 223 | -------------------------------------------------------------------------------- /2019.10.24.CQRS.Onion/CQRS.Onion.Simplified.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2019.10.24.CQRS.Onion/CQRS.Onion.Simplified.png -------------------------------------------------------------------------------- /2019.10.24.CQRS.Onion/CQRS.Onion.drawio: -------------------------------------------------------------------------------- 1 | 7Vhbb5swFP41PGYCc0ny2CTdOqndRZ02qS+Tgw24Mzg1zqX79TsGQwImXbclqlStqlR8bB/Mdzm26/jzfPdO4lV2IwjlDnLJzvEXDkJegJCjf13yWEcmQVQHUsmIGbQP3LKf1ARdE10zQsvOQCUEV2zVDcaiKGisOjEspdh2hyWCd9+6wim1Arcx5nb0GyMqM1Evmu47rihLM/PqCTLfl+NmsPmSMsNEbA9C/qXjz6UQqn7Kd3PKNXgNLvW8t0d624VJWqjnTPg+ebi5vvt4/+Ga394EJH3YsLuRN67TbDBfmy92UMQh4SwRkBeWrR4NFtHDWjQdo7Ji6gIGwBp2+054SvXf90UicZMKFlVnq/sMHm1iBAsFPqEx22ZM0dsVjnXPFiQFsUzlHFoePOJyVZOcsB0lei2M87ngQlaJ/CRJUBzrgZylBcRiAIdC52xDpWJA64XpUGJlPsVoDnlN26xLt0slxQ968AISLaMwar9BZ6W7o4R4Lc3gDypyquQjDDETUGCU0VjDNLd7nUWuiWUHEmuD2Gg7bVPv6YcHo4A/UENwVAzLPXenUMdC5JgVR+XRhpfnlwwJ6YQERxWSCcl+wuJwk4/jJeWfRMkUE4MKu+4NyBkhetW2Jmt1NWVlPKS3CVr60Yn05kddvQE5b0JLcu2oQ8m1wZNLzh+Q3FmoLkShUxBcZrqvmnACUIOx14BoYPU928deMABqGzw5qMgC9Wv1iNyPy3uAqGxtLRuDXRYKBEuHejYARWmxApCpLvySgu3xshrgQnslmJ4Io8OZEy40QWsl6tJQ8/W8Il0C4axIv+jGYhSciLdp1OctsnmbDtB2NtbsrbhbJv+Ckm49MRYYcMVvmWiL2JAFpVgXpDKVeyJywr6pgrFNzpCn0LnImVjkfF5TOWgYB83s4BUuAED5ikmLettLgF6YMs8ug/beUpALfUvQMHJcliwe4qLZoqPukdELrSNjlZ8S607RAxEuMVimVP2uhttgH4AZDoDZxCTlWLFNdxlDCJs3fNK1+uCo4Ha5nPY4KsVaxtRMOrxz9PKMu2nCfp4aBStPRXf70f+gAPt0saAr4JwWcWXdU+xpz3ZhdXKc4fhHWnmve22Bn6dsaK63ZiVOa5pDZT1hgqOmHblvvLC5yzbnwn+TkMky6s0QSVLS87BsX1vmIs+h4P4vzq2hp10n+sFLF+dw4LQTr/PXfbAJ/d4eOT0bDdDc/2+pttr+P3T+5S8= -------------------------------------------------------------------------------- /2019.10.29.CQRS.md: -------------------------------------------------------------------------------- 1 | - Command: 2 | - Message to change the state of the system. 3 | - Side effects 4 | - System may refuse to act on it 5 | - Query: 6 | - Message to get information from the system 7 | - No side effects. 8 | - System may refuse to answer 9 | - Event: 10 | - message that something changed in some part of the system. 11 | - System may not deny the fact 12 | - System may ignore it. 13 | 14 | The message exchange patterns could be request/response or one way 15 | ( publish-subscribe, fan in - fan out, push - pull, ...) 16 | The message exchange medium can be durable or not 17 | ( durable queue , in mem queue, .... ) 18 | 19 | 20 | 21 | ![CqrsOnion](2019.10.24.CQRS.Onion/CQRS.Onion.Simplified.png "Are Commands & Queries part of the Domain ?") 22 | -------------------------------------------------------------------------------- /2019.11.13.Zelazny.md: -------------------------------------------------------------------------------- 1 | # The Agnostic's Prayer 2 | (Roger Zelazny, Creature Of Light and Darkness, (c) 1969) 3 | 4 | 5 | Insofar as I may be heard by anything, which may or may not care what I say, 6 | I ask,if it matters, 7 | that you be forgiven for anything you may have done or failed to do which requires forgiveness. 8 | 9 | Conversely, if not forgiveness but something else may be required to insure any possible benefit 10 | for which you may be eligible after the destruction of your body, 11 | I ask that this, whatever it may be, be granted or withheld, as the case may be, 12 | in such a manner as to insure your receiving said benefit. 13 | 14 | I ask this in my capacity as your elected intermediary between yourself 15 | and that which may not be yourself, 16 | but which may have an interest in the matter of your receiving as much as it is possible 17 | for you to receive of this thing, and which may in some way be influenced by this ceremony. 18 | 19 | Amen. 20 | -------------------------------------------------------------------------------- /2020.01.30.Levitation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2020.01.30.Levitation.png -------------------------------------------------------------------------------- /2020.05.09.AnErrandOnQuestions.md: -------------------------------------------------------------------------------- 1 | # A philosophical(?) Errand on Questions 2 | 3 | Imagine a universe where communication is unambiguous and instantaneous 4 | 5 | This triggered me: 6 | ![trigger](2020.05.09.AnErrandOnQuestions/trigger.png "This triggered me") 7 | 8 | 9 | 10 | 11 | -------------------------------------------------------------------------------- /2020.05.09.AnErrandOnQuestions/trigger.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2020.05.09.AnErrandOnQuestions/trigger.png -------------------------------------------------------------------------------- /2020.06.16.ReactionToOverworking.md: -------------------------------------------------------------------------------- 1 | # Why did I get angry at the mention of 'working late' ? 2 | 3 | Yesterday we had a full team call, and someone mentioned working late... 4 | I told they shouldn't do that. 5 | Then someone else said, jokingly: "Hey look, have you seen my last commit time, it's passed midnight" 6 | This is a behavior I noticed happening in the last few months, while nothing calls for it. 7 | 8 | And I got angry, my whole body ached so much I got angry at them... 9 | And I reacted vocally, internally it was even worse. 10 | 11 | By then end of the day, after examination of my emotional response, 12 | I posted the following to our internal chat channel: 13 | 14 | > _Bit of context about "working too long" and why I reacted the way I did._ 15 | > 16 | > I know personally of 7 people who have had or still are in diagnosed **Burn-out**. 17 | > 18 | > If you take my close work related network into account, even more. 19 | > Those are people who have stopped working for at least 6 months to 2 years. 20 | > And are still now working part time, still in recovery. 21 | > Without speaking of their personality, or personal situation, and how it contributed to their disease; 22 | > one of the common thing that happened: they overworked out of their own free will. 23 | > 24 | > It's insidious, you don't notice how it affects every other aspect of your life until it's too late. 25 | > 26 | > I understand that in our line of work a certain dose of creativity and insight is present. 27 | > And that it's difficult, or even impossible, to switch off. 28 | > I understand that we want our system , code to work. 29 | > And that it's difficult, or even impossible, to switch off. 30 | > 31 | > And that we have this need to solve it now , whenever / wherever "now" is . 32 | > 33 | > I personally never looked at the hours I'm working...it's probably longer than I should. 34 | > That's because I'm a slow thinker, take a lot of breaks out of necessity. 35 | > If I'm at home, and feel the urge to do something for work , I give it a max time. 36 | > Otherwise, I would never sleep. 37 | > 38 | > For the "creative" / "insight" part it's not switched off , it's running in the background. 39 | > And I make a note of it, in my physical little black book, when I need to take it off my mind. 40 | > Writing it down effectively gets it out of my head. 41 | > 42 | > Now we're all grown up, everybody does as (s)he wants. 43 | > All I can tell from experience is to keep some _explicit limits_ that you should never cross. 44 | > 45 | > Now in addition to that: 46 | > At [redacted, a client] if you listen closely, there are people who are overworked, in constant stress, and as well in burn-out. 47 | > 48 | > One of the driver for me to push for the changes in the architecture, nagging about UX; nagging about a lot of the things we deliver is: 49 | > Let's deliver a system that free up people time, facilitate menial tasks , automate manual task, avoid the need to double check ;... 50 | > so as to not add difficulty and accidental complexity on top of the work those people do. 51 | > 52 | > Making sure they enjoy using the system. 53 | > Making sure they have a freed mind to do the complex things we will never automate because t's not cost effective 54 | > And make their work environment a bit more "enjoyable". 55 | > 56 | > That's our part in making sure people are less stressed out. 57 | > 58 | > In order to do that we must not stress ourselves out. 59 | > 60 | > Take care. 61 | 62 | To add more context: 63 | We're a small team and we have a _lot_ of work to do. 64 | We sometimes have hard deadlines, and we currently have one. 65 | Nevertheless we are in a lucky position: our job is not threatened, 66 | we participate and are encouraged to do so in disscussion about the business. 67 | When, for some reason we deliver later than expected, or something unexpected happens, 68 | no-one is mad at us: the work environment is one of openess. 69 | They are hard discussions, but always in order to look for solutions that are viable for the business and achievable by us. 70 | 71 | And for this I really need to give a big Thank You to some key people in the business. 72 | ( If you read this I hope you know who you are) 73 | 74 | To conclude, I'd like to share this quote from [Marco Heimeshoff](https://twitter.com/Heimeshoff): 75 | 76 | "Software development is not about software, it's about People" 77 | 78 | 79 | 80 | 81 | 82 | 83 | -------------------------------------------------------------------------------- /2021.04.05.AnOpinionOnSystems.md: -------------------------------------------------------------------------------- 1 | # An Opinion on Systems And EventSourced BLOBAs Systems 2 | 3 | _LOBAs_ :**B**oring **L**ine **O**f **B**usiness **A**pplications 4 | 5 | ## Systems 6 | 7 | There are all sort of systems. 8 | 9 | The first ones I had to study in a real abstract way were electronic & signal processing systems. 10 | 11 | This has biased me into abstracting solutions to problems into a series of components. 12 | Each component has a specific function with _inputs_, _outputs_, a process (some _function_) and eventually a _feedback loop_. 13 | 14 | ![a component](./2021.04.05.AnOpinionOnSystems/systems_01.svg) 15 | 16 | Except when building or troubleshooting the internals of the component, you don't really care what and how it really works. 17 | You only need _inputs_, _outputs_ and some _function_, describing accurately enough,how one signal is transformed into another. 18 | 19 | Those components are then assembled together, the output of one becoming the input of the other, to form a more complex system exhibiting more interesting behaviors. 20 | That resulting composition then becomes a new components that has a specific function with _inputs_, _outputs_, a process (some _function_) and eventually a _feedback loop_. 21 | 22 | That new more complex component can then be reasoned about without necessarily needing to understand its internal structure. 23 | 24 | ![a more complex component](./2021.04.05.AnOpinionOnSystems/systems_composed.svg) 25 | -------------------------------------------------------------------------------- /2021.04.05.AnOpinionOnSystems/AnOpinionOnSystems.drawio: -------------------------------------------------------------------------------- 1 | 7V1bk9q4Ev418whl+e7HhMzs7jmzlaQmW5vNy5bBmsEnBlHGzCW//sggGVvyRfINmzGVqoyFEMbd/XV/rZZ0oy02r7+F7m79J/JgcKMq3uuN9ulGVYFim/i/uOXt1OKYpOEp9D3S6dzw4P+C9JOk9eB7cJ/pGCEURP4u27hC2y1cRZk2NwzRS7bbIwqy37pznyDX8LByA771b9+L1qdWW7XO7b9D/2lNvxmYzumdjUs7k1+yX7seekk1abc32iJEKDr9tXldwCB+ePS56N++zr6tH/6zXX/66zlA33/APxaz02B3Mh9JfkIIt1HtoWe/vj3+WHxw0b/fIvDhrx/2m2POVGCQHxe90ScGPfwAySUKozV6Qls3uD23fsRPYhe/+xjA1w+xjHBbiA5bD8bfBfDV/w6bHR1ji7bxh85D3SO0o/1gFL0RpXEPEcJN62gTkHcDdwmDj+7q59Nx9AUKUHi8R+3x+IpvJXLDiAxg4Gu49cgdfVoGaPXz1HTnB/GYyvEDIfoJU0N5lrNUzu9QJYm//xF/LPOl0Fyt4na0je7cjR/ENnF/WPmeix/hAm336Ph84vfJPQFArlPjKMfX6c5Sty4oZaINe3QIV7BUtBoxNzd8glFZT4X0jCWfshqiR79BtIFR+IY7hDBwI/85a1ousdCnpN9ZC/EfRBGllNKclPJySvnqR9/Jd8V//xPf49wgV59eyS0fL97oxRbL/fu5Y3z5T/q988eOV5nPfYGhjxUHhkljl1ahCFsFaN0qyEe/IB//FlUhPla1CAYTD2soSnaI062STzG2ldxGfXMDqn76vmc3OJAfwdlfrOw7OVk8wzCCr5mHQpy8u6TDKvlPlHzKVDIPhjril7Mf12jbOu3DdaVYBqLIZHyFn/99QPjf0+rudr/4uvzvA/Gw6Qf1JUQruN9zz+uMPLFKv6z9CD7s3KNqvuBAKwspvPmbS9MwGaNVRY2c3EUJWBH0Y6DkDr8cB7djMUWuv00skpd7hSKxki+UMFAqRQzyRGy3IOHc32BVm0IOmnOyTAN2nmOqkmPWPTBy8lxoP67y9MZc2XBZ4IEyVxSuM2A9V40KvJZVhDTIlhlUJcQSdZmp+eoiAbbZAVikOPkPDmq5YVi9NfqFbJvT0j+2u0OUGzXdxxAQx0Jw7/8iyKtkddYN/Kct/nuFxRob/cfYgH3MoT6QNza+5x31sgJPGqJVTdyxypyLEBr1E9cCpym4CETBfLxYIQSBePbUBYUeDBmJ54TUReBiVYFLHk6KhslFQXEW9zhUrBHqykJgOiItg8ABQqVRjnGiWDkD2XGAYHyLdcB9S3XbxR32JffLhIumUnpbbHcaZxT1b9bdzvTGf5x+XateQeXD0zsIvSW27e49Q7eRat2I1BmJa6CeoMw1SFGKakctmiugwszLFXDqkcbhhqKTIBO9EMLcu2zs0dvK2nCSkEkpVXveev5VVtTCvk1jPcocWErqpUr7OlWZpwcAWc/nzG2tnvPTlFyn1Ftuh3cJnw9RL1RB1iEcEesL2vuRj3K/4Z7pEMUJ2378yFjcCNDNakC6SCpPZ0yWInI60aPnQDdrL+09Ks1o2eVeSxYv0SHhLJ7BwjEn2zzRap2JVudR771HUxJCvZxJ6gITEUMJp1KpVjacEkze0nKCuFN2onL/E0ar9U0yHUYHNwpiNSoxNRORaXMAmKBMo9fpEWVVSDwDoWdxYaY5c9Nwzi9LNkxjMglsTkM0KDPKh5HOR7QetekCvmkohlDCK8Q4xKUModlEt2RyU9bIKieyk/ilciI76SlsuICxsxlgDNe0pS1Xz4//hE234HMt5Q65eUijFEDY7np5LrBgtqiouyXVW2vSW9MY/OogLQl0yiImNGsFzWytJTTjqp+6RSpx/GHmLmZqc/zR2gkduHGMocUOpkAK4Mp5rVQqo4TVMrQ2J2fRL681BapTrpbXtiRUtqYsJ1nRM+s1+WqOwbrHa2a9ZQom6rpYhuooc01PzStoxUqU7290dtq57iw8h2aCJUt9eq7rmE0bTJw4RNbbqHg7iW2qOa8pmazSGH6KKXBDyzUcZkSrpuXqbHqdHaglDmyw32OUk2Cuv1VOPbn+dkV/Va6/bjfsb/ZBhqnwJpAbJxluB8CEYYmrdGgMS6zW1w4ouIEGR4UtgfmkiQoLqCHnghyeNfVLha0RzZBMpKliEZCjs9o1B43KuXQmmqtdu8zGCKILPXoEOVuttoRBrN7TeMzQQA5ogO5SLZY2HtQYQ/CVixq8npUrrjhMsLMC+tx20uUE0vUEbIWCpWNOmx6yHmpoTBbIGlxkZAtMyRWARgUK1YeNFC4k6zv7wgWBFOzVJtYrNEQ4SMzB99ygkGMcLabS2w7464Xl3cmXYQ3FfKQ7MVcXe2p5Qu+QCoyovOB6qEDna8ipZgrkemWXj6g0DZOkLhi+IZ5VoQVAtZeHyMQfl48bLIHigqHY2vUH0JI8m80lGnMci6W0Xjp8ZjOAAAfkdj1DYEvkABhczGw13htk0v2h6P7MbFqKzug+G97U1Xt2nMurvd42NxpfEr2t0LmoCPFyC6UEKi4m3iu5h1VeRZmSI9bu0hmUoo3BU10RIyKTzvFKcv0mPfGs0TnpgvIafMFugiirrtVTz9TWxauwmQR+C1XYTktOk13FMDinaYwoJzHaWHGQC7gkDJKYT3WCg/asuz/GrLHhsvvm1Z1PtcuHaWs1FxucV6zmyr8r0e4V+0wBQ647aNRd76OGzVAndBtPDVtqc2ZFBVnYA45agXu5WzRfEgwt2TiGXYXefDErW+VfN47hxhlczsuYKui6Iv8JJ7wY+zfa3gFnYv9nilPF/rubBDdGNEdzhexfwl2370YN6aXWjHc0jOxWevQoDomV1ux2r/GskJryt3VniFj8HN4MkTGilZxTXJzExTMcGDNxsQ2ShsvGxTQA6yAuVlmi2XBlCTe/DOqGxSOYC2574uT9xsUsCbp8QRnN70ww3mXytq9EbPv1Y+y6VM1oipzMjk9svXjdnfYdxkTa2mjfzr3dQjjn1tmWpzTZxyvZvWIvLra7YjOA0UXC1BFYdzKIbXk1g0ff/CJu9hCHFuF3Kkoo1B+p3Vt7FxyfLPzd3XoB/rlTbCQnxYICS9448xbKdHY4GrAbr7od8/FobUUmVA+q2R+FwuoYxpaMYWYVe+BWBy1ssFH3KLX83S5b39ykbIq3I69v84nYBdpsMCTyRvMuDmpL8GP4BynQ0HnkHLCrk10ald6Ai8OqcFLNlk2qsdu1KY3T6U7VyTSZ3LpeD4RVJ3sGseAWU+0RJL5e7vYZ0uzddE6NsA0oowFYgcqCi1Bitrorp0i/b2LlTBP1heozaEbs8BHgxIjrSXGgjNh51weGtxa66aKhmyN86oUje1zNxIi7z4PzBRLvnBE74zm8/Dp2Z35XjFgcVoU3VnZkK8wmRlzvLG8+ATUx4joAO5azW1WFz4Fwsh4CI9ZzzkHpmVipdEvQiRHz6jNkRqwqfCXExIjrSXGYjFhVGh/iOjHisx5Uhm4JFFaGbontTYx4MIxYVfjU7vtmxAl+jCBgG9FCq4kRy8KqJgyrqiSsToy4nrnxqfaJEdcBWHMsAAsEyqYpeq3eAh/ThVCr5grLE7G4XyYNySP+fIjwMPT57+kKBi31Uo3jEgVxWlCDQyoyWM/LvZ1DX9gDHAzTmRscuchbm1NjaQ6+DBGK0pCB5bb+E3mxFd/+Hw==7Vrdk6I4EP9rrLp7GIsPAXlcUW/2yqudq6m7232MEDE3SDyIo+5ffx1IgAAqqDM7V3U8KOl0Okl//LoTHZje5vBLgrbr32iAo4GhBYeBOR0YhqU78MkJx5wwsrWcECYkyEl6SXgm37EgSrYdCXCqMDJKI0a2KtGncYx9ptBQktC9yraikTrrFoW4QXj2UdSk/kUCts6pY8Mp6Y+YhGs5s267ec8GSWaxk3SNArqvkMzZwPQSSln+tjl4OOK6k3r5/fNC22pH7Yv+qBn+S/yPNvMecmHzPkOKLSQ4ZleLnr4k1h+/uofwOIuevKk/+5MiMUR7RdFO6EvslR2lAsOE7rYdVyBW+ooThg9t5kVLKbbUIHgephvMkiPwiVGG9DLhdZY0wr60YcGzrtpPE0Qk/CYsZJe6gRehnh6q0i+rCjQVB5gL0QbmZL8mDD9vkc979xBcQFuzDUw61eE1QkscTZD/EmbDPBrRBLpiGgP/ZEVjNkcbEnEFLHY+CRDM5dE4pZHsF8GmG6ItRQwMU8seoKOIhDHQfDAcTjgjiaLaXGAbhkjMu7OFN4191nfqxj5p1Ic2I47f1YhGw4iPKA4i2LphRzD7ZMnfQv72057AIrl9EcM/32brlCX0BVfsE9hL27JP2PGi3cUqOnhRxdgw6xwe131Hi9eiWG/aXzda7D9+K/Obl2MYx8EnnnagtYyo/9JmSJlIMsoabfnQVYQPYuBFI8Icc8JXnim/ZqQA4fHKb3Ma2x/j5SrrQYn0GiuXp7RAVV+F8KzxjTeGRd/0UO2cHq9ygpTuEh9fxktYaojPyRMmwIGSx0+DiKX6lHHGV4SQJ0pgR6UEXZUwqknIdyYGVRNqTY5TS1E1MfnGG2LAR9CxwrblDOnp1Vqts5RBkMsrQ6LQ2PVRMmpEiUc3G8DJZrCA0RYcgcB9EpyS7yK/a2rUNJIQRxACNdon0bEhQZBFxuWkeAtYXgl75rkSphMcJjhCjLyqJend0c26Fd36FB2Sv1PR0cx/jrvMWLsBqgqYKtw1wPBA2Fchi79XwA9aJfbxxnFQAcJiUHfIbOTXme1594dSoyOU6j2htJGeh7qjlY9u94VW3dWGWlWCil3ucGy45TMeXQe8hmspcp1uyHsveLQbYTZ7xQLD3xYd++JfhqZPNCWM0NYZFjUGRre9a8wrQdX6j4CqcxlUJWL5x4jAmSAxLx8IlvnpYbEsCIV6v+wYiJG6T4W5rVbN9jqEn8QBs4YDjtas00ctZbr9VmW62xpK0iVpwtY0pDGKZiV1op7HSp4F5T6d6fJvzNhRxA/aMaqaROYN7Zq8oZbaZ7KG6ZRJ5QknBBRWRI6/S16zHeRZqMjUItDUJBigdF0w9/OMu5XuTsd88z6RKsv6Sqh+XkH7G901T/cpguVwrMwK27TJkAmoE4s6WHvmOiRxeBb0rwL5eqYQBwQQbk0G1vQ0HkMB4rqeN58XLDQBNGor0DpitHsCSXpf50Fh4Y6FtM7OcKLEGI5MBa0eLAipmhi6WqX4TZK/rrda/I2xSQn2RjFcw4k7g0HX4vODgUHzpi8Dg+MZMHjmN30dkUDwflAcKC767oMD+t3u9bWhMXJsNX6N23DhHWLe/CH1SPuZ9MraoheCqIXIFefp/+sRvurmPZrEkXSLYokkF2FJdhBJn+xSOCCkRdECqyv64Btt+GEjXqb8Sx5N20FNYW0yZYMVkCsmrO7go2Hf1LXt+2Gf/M3gZux7APAzx+rVxQ/EPmiWv13n7OUfAMzZvw== -------------------------------------------------------------------------------- /2021.04.05.AnOpinionOnSystems/AnOpinionOnSystems.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | AnOpinionOnSystems 6 | 7 | 8 |
9 | 10 | 11 | -------------------------------------------------------------------------------- /2021.04.05.AnOpinionOnSystems/cqrs_saving.02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2021.04.05.AnOpinionOnSystems/cqrs_saving.02.png -------------------------------------------------------------------------------- /2021.04.05.AnOpinionOnSystems/cqrs_saving.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2021.04.05.AnOpinionOnSystems/cqrs_saving.png -------------------------------------------------------------------------------- /2021.04.05.AnOpinionOnSystems/cqrs_saving.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 |
Handler
(with state)
Handler...
Command
Command
Events
Events
Save Commands
=
Command Sourcing
Save Commands...
Save State
=
State Sourcing
Save State...
Save Business Events
= 
Event Sourcing
Save Business Events...Viewer does not support full SVG 1.1 -------------------------------------------------------------------------------- /2021.04.05.AnOpinionOnSystems/systems_01.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 |
Process
Process
Input
Input
Feedback
Feedback
Output
OutputViewer does not support full SVG 1.1 -------------------------------------------------------------------------------- /2021.04.05.AnOpinionOnSystems/systems_composed.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | -------------------------------------------------------------------------------- /2021.04.30.OnPrinciples.md: -------------------------------------------------------------------------------- 1 | # On Principles 2 | 3 | A few weeks ago, the following question popped up in the DDD-CQRS-ES slack 4 | 5 | Here's the exchange I had with the original poster. 6 | 7 | (reproduced with his permission) 8 | 9 | >Hey. I created this principle to help with scaling decisions my e-commerce team will be facing. Let me know what you think. If this already exists, please advise. 10 | > 11 | >Scale-Conversion Linearity: 12 | > 13 | >Definition - 14 | > 15 | >The ability to scale a distributed system in direct proportion to the business transaction demand (conversion of prospects to actual customers) of its users and no less or more. 16 | > 17 | >Rationale - 18 | > 19 | >Building for scale requires trade-offs and overcoming design challenges, increasing the cost of the system. There are diminishing returns for this when the purpose of the system is not fulfilled resulting in cost that cannot be offset by income. Conversion of end users into paying customers (or the equivalent of revenue generating transactions) requires other aspects over and above scaling, such as pricing, segmentation, range and fit of offerings etc. 20 | > 21 | >Implications - 22 | > 23 | >Partnership between the engineering teams and business teams is required. 24 | > 25 | >A value must be placed on scaling units that can be attributed to cost offset. 26 | > 27 | >Negotiation points to refactor the system to break through scaling limits must be instituted. (edited) 28 | 29 | 30 | 31 | 32 | Nice and succinct! 33 | 34 | It does tie the engineering effort cost to the value generated by that part of the system. 35 | And points out the need for collaboration between dev and business. 36 | 37 | I do miss the need for continued reevaluation and operational cost 38 | 39 | Question: who is the audience of this principle? 40 | 41 | What I sometimes do is have a set of one-liners summary in business term that encompasses a series of such principles. 42 | They are reminders for everyone to help set context and priorities. 43 | 44 | E.g in my previous domain : 45 | > All candidates must be able to enrol at all time. We do not send candidates home. 46 | 47 | It is phrased in a way the business understands "All time" instead of 24/7 48 | 49 | This one-liner encompasses a subset of capabilities and systems. 50 | 51 | It also implies priority: if there is a serious problem with taking tests affecting lots of candidates... someone needs to stop whatever he is doing and help the operational teams. 52 | 53 | Implies where the scalability and availability need to be placed. 54 | 55 | Implies the need for metrics and KPIs that are useful. 56 | 57 | Allows us to say "this is less important than that" 58 | 59 | In that place, I have 3 of such one-liners. 60 | 61 | The implications, for dev/ops/business, are ofc broad and not detailed. But once in place they did allow better reasoning & bargaining & negotiations. 62 | 63 | One thing to note: they are about what we consider the core business. 64 | 65 | So it's easier to say: 66 | > we need to do this ourselves and fully understand 67 | or 68 | >this falls outside of our core principles, so we will not ..., we will limit the effort... 69 | 70 | Practical examples: 71 | 72 | * A few years ago we had a major outage. 73 | We had people nagging us from all part of the business and external users... but that one-liner allowed me to protect the rest of the team from lots of those: "yeah I understand that this is a major issue for you right now and you can't work, but the priority is making sure that candidates can take their tests, and they can enrol in selections" 74 | 75 | * We use EID authentication for candidates & back office. 76 | It's more important to have alternate authentication methods for candidates than back-office 77 | 78 | * Some 3d party subsystem/services are used by candidates & back office. 79 | When there is an issue with such 3d party that affects candidates, we will be following resolution way more closely and require or create a way more detailed post-mortem report of who was impacted in what area, for how long. 80 | When it impacts the back office, we will make a more light post-mortem report. 81 | 82 | So those one-liners are a distilled version of all the more detailed principles 83 | 84 | 85 | 86 | PS: thanks you for the kind words Lyronne: 87 | > @ylorph If you wrote a book in the ilk of the above comments, I would not put it down. 88 | > Thanks for the deep insights, sir. 89 | > The audience is my CIO and to be floated up to the Digital Programme Board. Really poignant stuff! 90 | 91 | PPS: putting this out today because of a discussion with Chris 92 | -------------------------------------------------------------------------------- /2022.02.10_my_vs_ours.md: -------------------------------------------------------------------------------- 1 | # My versus Ours 2 | 3 | My idea versus Our ideas. 4 | My goal versus Our goals. 5 | My problem versus Our problems. 6 | My work versus Our work. 7 | 8 | We need to strike a balance between "My" and "Ours", given the current people needs. 9 | 10 | What I noticed, in _my_ experience, is that solving "Ours" solves "My" as well. Most of the Time. 11 | While solving "My" _rarely_ solves "Ours". 12 | -------------------------------------------------------------------------------- /2022.03.23_common_ground.md: -------------------------------------------------------------------------------- 1 |  2 | 3 | ![common ground](2022.03.23_common_ground/common%20ground.png "Especially if we discuss differences in our own bubbles") 4 | -------------------------------------------------------------------------------- /2022.03.23_common_ground/common ground.drawio: -------------------------------------------------------------------------------- 1 | 7Vhtc9o4EP41zF0/wMiWbcjHAEk6vfamN+n0rh+FLbAusuXIIuD++q4sGb+SkknCZeYKM2DtyrL2eXa1ux7hRbK/kSSLP4mI8pGLov0IL0eu6ztT+NWCwgi8ABnBRrLIiJxacMu+Uyuspm1ZRPPWRCUEVyxrC0ORpjRULRmRUuza09aCt5+akQ3tCW5DwvvSv1mkYit1gota8Z6yTWwfPXOtwQmpJltL8phEYtcQ4asRXkghlLlK9gvKNXYVLua+6yPaw8YkTdUpN0R/fbm7d77S+w/Fpz//oDfh97E3ds0qD4RvrcF2s6qoEIBVAGwYzHcxU/Q2I6HW7IBukMUq4TBy4DJXUtzRheBClnfiKFgFfgAaAfcwpT3AQzBcM84b0xB8rmHX875F1sgHKhXdN0TWwhsqEqpkAVMqf6vQtu7mIjve1eThak7c5M3KiPWXzWHpGlK4sKg+AWH8mgivZr7noxbCeADh62uN8csgjN8cwl4P4YVIEpGO3IDDs+cr2YI7uN/qkJuvRarGeXngXMIEB2f7EqFKD1cb/X8jxTaNeqQBXOoxdlKR0g4TVkQ426QwDIEECvK5Bp/BkXNpFQmLIn7MHcrdUI0HskbYQ9PB1dhucuCEeHo8BX6bbdxn2xsg230tsoMe2Uu2XlMwEUD6f3LkIfRTjpyhiHw1kqa/SOqSFPhvjaSLHhNtRIRUsdiIlPCPQmSWmn+pUoXFiWyVaBMH8MjiH33/ZIa9SvDNCGazSrDc20eYUdEcfaaSgX2azuWjGSsXWxnSR+ybmXmKyA1VP0/QNGoVgn0iJeVEsYd2XfjirMx6ofORqt9yXboynYWQimlZ7poMB1WzyU5oMpm8QmhxulbPC6xu7fdonOE5JyvK5yS8M4Y1iph1+XmZIsabtaMRD0TjoQU5SzQ6To897ZEVNHUwXtXSLtLPCljcDtcL/7zRWoF9/nAtb72UkhSNCZlgqcobK3/WgoYDOUHbgWao4wJmxdohDlt7ho8MtA5n9ZGp33GSAL9RL3HfhJdMA/QfeAnqpRDIDSu6FlJnjojl4TbPWbo5JJPoUJzlv1LIySmk0xnh6UAKwf45U8jQqwbTAmcl9Ud64DVJGC9MFwwqkmgG7AQ4GlaSsFQXIFBwiK5+5C6sJjcMggRxltJxZXLZW+sOxTfKbtuNjrTdC5EVslzCRb+H7+AXvtq8kYcKYDSLS0WpWRXjnMC/N0GVxYBgabRZ7AS3Pr2ZkBS2T1blUtof7SkA6/rzkb/Ua8EhmlsPPRYxJ3hp09Ff6O2N3+kVvYG3N24wUPh4T/daGNZvN83pVr8ixlc/AA== -------------------------------------------------------------------------------- /2022.03.23_common_ground/common ground.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2022.03.23_common_ground/common ground.png -------------------------------------------------------------------------------- /2024-02-19-EventStoreDB-typical-usage.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ylorph/RandomThoughts/c7ea9d2283984d6d8cde8460fe1926df28e1242f/2024-02-19-EventStoreDB-typical-usage.jpg -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | 2 |
All Content of this repository, 3 | unless otherwise stated, is licensed under a 4 | Creative Commons Attribution-ShareAlike 4.0 International License. 5 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # RandomThoughts 2 | Some Random Thoughts I have 3 | * unordered 4 | * unclassified 5 | * unfinished 6 | 7 | This is just a way for me to keep a trace of them 8 | 9 | 10 | 11 | 12 |
All Content of this repository, 13 | unless otherwise stated, is licensed under a 14 | Creative Commons Attribution-ShareAlike 4.0 International License. 15 | -------------------------------------------------------------------------------- /analysis.md: -------------------------------------------------------------------------------- 1 | # Analysis 2 | 3 | 4 | * event storming @ziobrando 5 | * impact mapping @gojkoadzic 6 | * C4 @simonbrown 7 | * user story mapping by @jeffpatton 8 | * Wardley maps @swardley 9 | --------------------------------------------------------------------------------