Let’s talk about one of the undecided problems of building software: deciding what the boundaries of a piece of software is.

How to draw the boundaries:

• A group of functionality that business customers see as a single unit.
• A code block/module that developers see as a single unit.
• An initiative that those with the money see as a single budget.

Well, we can draw application boundaries in hundreds of different ways. In many ways these boundaries are drawn primarily by human inter-relationships and politics rather than technical and functional considerations. It’s an uncomfortable fact. And people usually forget: the heart of software’s its ability to solve domain-related problems for its users. The “technical” problem doesn’t come from technical side itself.

This is not a post about specific technologies (I’m good at click-bait, right?). This post’s not just the code but the model underlying the code. Communication between domain expert and programmer’s a key here. Each organization has some distinct things but the steps are the same

• Getting all team members to speak the same language.
• Connecting business model and implementation more deeply.
• Managing the lifecycle of a domain object.
• Writing domain code that is safe to combine in elaborate ways.
• Dealing with legacy thing on the same project.
• Maintaining model integrity in a large system.

I think if the organization can do all the steps above, its product owner, designer and developers will have a guidance that they need to organize and focus their work.