Subject: domain model to design 2004-08-11 - By Jin Chun
Back
Hi Pradeep,
try going on a different level using robustness analysis (this is a
diagram which is supported in together).
In case you aren't familiar with it, it is a way to flow out the paths and
interconnects between the components
in your model. There are basically 3 model components with the following
relationship (from memory ;-),
Boundary - these are components which interface from the actors (actual or
otherwise, e.g. system type actors), such as
html forms, jsp stuff, etc.
Controllers - these are the "manager" elements, which implement flow and
business logic.
Entities - things that are persisted, such as an MI interval, person thing,
whatever.
The basic rules are that actors only talk to boundaries, boundaries only
talk to controllers,
and controllers are the only ones to talk to entities (directly touching
them via crud to the persistent store).
If you model out these relationships in your use cases and domain model,
then you can synthesize the controllers into session facades, including
whatever interface/abstraction you are using to encapsulate the hibernate
operations, your business model elements become pojos which are
passed between the boundaries, controllers, and entities, and flowing paths
becomes a little more sane.
Jin
Jin Chun
Vice President: Sr. Systems Architect
State Street ? Global Link | www.statestreet.com | www.globallink.com
617.664.1695 | byungchun@(protected)
SCJA SCJP OCP-DBA
Confidentiality Notice: The information contained in the email is intended
for the confidential use of the above-named recipient(s). If the reader of
this message is not the intended recipient or person responsible for
delivering it to the intended recipient, you are hereby notified that you
have received this communication in error, and that any review,
dissemination, distribution, or copying of this communication is strictly
prohibited. If you have received this in error, please notify the sender
immediately and destroy this message.
|-- ------+-- ---- ---- ---- ---- ---- ---- --->
| | Pradeep Kumar |
| | <TC00328@(protected)> |
| | Sent by: An interest list|
| | for Sun Java Center J2EE |
| | Pattern Catalog |
| | <J2EEPATTERNS-INTEREST@(protected)|
| | VA.SUN.COM> |
| | |
| | |
| | 08/11/2004 12:40 AM |
| | Please respond to An |
| | interest list for Sun |
| | Java Center J2EE Pattern |
| | Catalog |
|-- ------+-- ---- ---- ---- ---- ---- ---- --->
>-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --|
|
|
| To: J2EEPATTERNS-INTEREST@(protected)
|
| cc:
|
| Subject: domain model to design
|
>-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --|
Greetings group,
We used to TogetherJ to get our business domain model (or problem domain
model) using color modelling. We are not sure about the best approach to go
for the design (next step). We would like to retain most of the business
model during the design phase. We are planning to use Hibernate for
persistence and stateless session beans as facades. Our business objects
are between these 2 layers. Also, our framework classes are in place.
The confusion is mainly due to 2 archetypes (actors and moment intervals).
We are not sure if they should be persisted or remain as POJOs (non
persisted POJOs) or remove them fully/partly based on business context.
We looked at FDD (feature driven development); however, we are not getting
a clear picture.
Does anyone know of a good methodology for transforming the business model
to technical design?
Thanks.
Pradeep
====================================================================
Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
http://java.sun.com/blueprints/corej2eepatterns List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
|
|
