I’m a huge fan of code as design [1], so I tend to do my architecture thinking at a high level - the objects and interactions between systems - and then write clear and simple code which expresses my intention. To this end, if the code is clear then it doesn’t need to be documented heavily.
I’m also a big fan of DDD [2] and use his “box and line” drawings all the time. There are loads of resources for DDD but I’ve linked to the book, which is awesome. DDD has great concepts like Context Boundaries and Ubiquitous Language which may simplify the documentation process.
It’s easy to think of architecture too abstractly or in terms of frameworks or other complexifying concepts, but simple is good, and that’s true from top to bottom.
I’m also a big fan of DDD [2] and use his “box and line” drawings all the time. There are loads of resources for DDD but I’ve linked to the book, which is awesome. DDD has great concepts like Context Boundaries and Ubiquitous Language which may simplify the documentation process.
It’s easy to think of architecture too abstractly or in terms of frameworks or other complexifying concepts, but simple is good, and that’s true from top to bottom.
[1] http://www.developerdotstar.com/mag/articles/reeves_design_m...
[2] https://www.goodreads.com/book/show/179133.Domain_Driven_Des...