Business-centric interfaces encapsulate abstraction better than data-centric interfaces.
Data-centric interfaces typically revolve around CRUD activities, while business-centric interfaces focus on actions occurring at the level of the business. All software is about the business activities rather than technical concerns, at the end of the day, so it stands to reason that structure based on the business will convey more relevance across systems than CRUD descriptions will. For example, Employee Deleted does not convey as much information as Employee Terminated—while the former could include the additional semantics, the default implementation will omit it if the source system does not value the additional data. There’s a real chance downstream systems do benefit from it though, so everyone agreeing to discuss the business instead of technical implementation will reduce data loss and complexity. If the interfaces expose the source schemas directly, then the clients will couple to it and make changes harder, breaking encapsulation.rC6
-
↩
Derek Comartin, “Event-Driven Architecture Lost Its Way,” March 7, 2024, https://codeopinion.com/event-driven-architecture-lost-its-way/. (See notes.)