Bio

With 15 years of experience in designing architecture and leading groups, Ora’s passion lies in the connection of building an architecture that empowers and motivates teams to take e2e ownership on products.

Currently Ora is R&D Director at Taboola, leading the Publishers R&D Group. During the massive growth of Taboola from 400 to 1000 in 2 years, Ora came across DDD and practiced it for building autonomous teams which are strongly connected to the business. She is also an active member of the DDD-IL meetup group and takes on herself to spread DDD knowledge where relevant. Besides software engineering Ora also holds an MBA from TAU where she also mentored in the GBS excellence program.

---

DDD Case Study: Oops, I DDD it again (and again) (Talk, DDD Foundations 2020)
by Ora Egozi-Barzilai

Using DDD for mapping a company’s core domain is quite known and one can find many case studies on that, but case studies for merging or re-dividing domains upon acquisition are harder to find.

As an R&D director at Taboola I had the opportunity of leading a technical due-diligence of an acquired company. During that time we considered a few alternatives of how such an acquisition might look like from two main perspectives: organization structure and technical integration whereas the two obviously affect each other per Conway’s Law.
In addition, post acquisition previous assumptions turned out to be inaccurate and required further domain analysis, for finding a better solution.
During those challenging times, I found DDD to be a very practical tool for executing the relevant change.

If you are in a dynamic company where teams, products and domains grow fast and then split or merge, you need to constantly analyze the domains and consider alternatives for those changes. From my experience, DDD approach helps visualizing and considering these alternatives while being able to keep the discussion both business and technical.

In my talk, I will share the two years journey post acquisition. A journey in which domains merged and split due to a dynamic environment, for example:
Why we used DDD to decide an acquired team should stay as an isolated domain, acting as a supportive domain in the company
How we later merged part of a supportive domain into the core domain
How and why we ended up splitting the merged domain again