I often pretend that some parts of our platform are actually services provided by third party organisations. Doing so helps me draw borders between our products that have large overlaps. This way I also avoid irrelevant details and stay on the right level of abstraction while solving a design problem.
For example, say we are working on an educational network that offers services both to universities and students. We have two products. The first one is a marketplace of online courses. And the second one is a system for universities to process student applications. It is expected that students who complete an online course will be interested to continue their education by pursuing a degree.
Both products have concepts of students, universities, courses, lecturers and tutors. However, these terms have a different meaning in each case. A course in the online learning portal is a single product to be purchased by a student. It contains all the relevant educational material. As for the university applications a “course” is just a title and a description of a course that a student is going to be taught as part of the degree.
You can imagine how much more complication this can cause with hundreds related products within a platform. And I don’t mean just database representation or classes diagram. Trying to cover everything within the same language affects designers, copywriters and even customer support. Think the reverse effect of the Conway’s law. The one size fits all domain view makes internal communications more complicated.
Let’s now imagine if these two products were built by two different companies: the University Applications Ltd and the Online Courses Ltd. Each of these companies would have much simpler worldview:
We can let each of the imaginary companies use their own language. As a result the terms scoped within a specific context will be cleaner and more straightforward.
Let’s imagine that these companies have built two completely different web applications. Some time passes and University Applications Ltd acquires the Online Courses Ltd. Now they need to talk about an integration.
They quickly realise that the only integration that matters is that students can use the same accounts across the two products. University representatives managing online courses and application administrators are employed by different departments and are happy to use separate products - each suited for their own needs. A simple reporting tool will easily let analysts combine all data for a given university or student across both databases.
Mental experiments like this help me ensure that distinct parts of our platform always have one and only one duty. Just as the Unix philosophy teaches us: “Write programs that do one thing and do it well”.